[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-----
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?
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
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
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-
) 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
-----END PGP SIGNATURE-----
Main Index |
Thread Index |