Port-sgimips archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: O2 framebuffer problems with install kernel



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

Hello,

On Jul 28, 2008, at 10:16, Jorge Acereda Maciá wrote:

On Jul 28, 2008, at 3:48 PM, Michael Lorenz wrote:

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?

Yes.

Thought so, this is a known problem.

Will the framebuffer work if I install through serial port?

I seriously doubt it.

Meanwhile, I've installed through the serial port and got it running in multiuser state through the serial port. The installation process went smoothly. But the dmesg says:

crmfb0: device unusable if not setup by firmware

I'm new to this boxes, so how do I configure the width and height? Should I post a 'printenv'?

You don't, crmfb will use whatever the firmware sets up.

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.

OK, I'll try to inspect that module.

After a quick look, I've noticed that 'defattr' in crmfb_attach() seems to be uninitialized, but that can hardly be the reason.

That's harmless and should be initialized by vcons.

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.



Given that I reach multiuser, can I discard this possibility?

Not really - as I said, unaligned writes there are silently ignored, unaligned reads just work so you wouldn't get an error either way, just malfunctioning drivers. The other driver that might get bitten by this is mec ( the O2's onboard ethernet ) but I don't know if it uses any bits that would be affected, IIRC most of its registers are 32bit aligned to 64bit.

To test this please do this:
Look at crmfb_attach(). After mapping the drawing engine's registers ( rv = bus_space_map(sc->sc_iot, 0x15000000, 0x6000, 0, &sc- >sc_reh); ) write some random but recognizeable value into one of the drawing engine's TLB registers ( like this: bus_space_write_8(sc->sc_iot, sc- >sc_reh, CRIME_RE_TLB_A, 0x1122334455667788L); ) and read it back a little bit later. If you get the same value you wrote you're fine and I'll have to think of a new way to screw things up, but if you get something like 0x1122334400000000 or some random garbage in the lower 32 bit then that's the problem. If you do this right after mapping the registers it should run even on a serial console, the code that checks for firmware setup come later.

have fun
Michael

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

iQEVAwUBSI3lGMpnzkX8Yg2nAQLo6gf+L4p70vd73a8JATQsYn9ERCO2ND6JqZ/O
SEDQoBcoQwr19CsPGWQRMm6tDSmDTKFkBuvWoksINBYYP2TUk9RZoO8nHe/g/w+d
65vZ9kmxE6op6i/zDVVqKZne0wJ/nORaM2UVzl7eXbdBbBVz9y0b/rEMsAC5OuTn
gqt5hsThz8mRnf+KP6rq6hc9vJe85AWvs/OA7COggbdIEyhRgbjtIE6cHnoxIq07
ZPBiVv5TgjZOHF5a/Nk/lxhLQe2ZHE170dGip1h2qXFsw5Cks/B1c3yBgx2fvnH6
CoYZ2ls7dzCH5pfb5qdSUIMWTfpuDSsYEvndFkImbNxqcK5CTUyh5A==
=OCQ0
-----END PGP SIGNATURE-----


Home | Main Index | Thread Index | Old Index