[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: machfb MMIO versus SPARCle OFW
On Mon, 21 Oct 2013 21:09:04 +0100
Julian Coleman <jdc%coris.org.uk@localhost> wrote:
> I tracked down why my SPARCle (SPARC laptop) appears to lock up on halt.
> The cause is:
> where we use the MMIO registers and alter the BUS_CNTL register. This is
> a problem because altering the BUS_CNTL register in this way [*] causes the
> OFW console to stop working when we halt.
Eww. IIRC that's supposed to turn off the register block that lives in
the upper 2KB of each half aperture, it didn't cause any problems with
other other Sun or Apple mach64 OFW that I have here. Should really
only be done when we have 8MB VRAM and the registers would overlap with
( Mach64 has a 16MB aperture that's split into one big and one little
endian half, the register block exists in both so with 8MB there's
overlap. Not-so-ancient models have the registers in an additional PIO
BAR, the last few generations have them in yet another MMIO BAR. The
plan is to use MMIO whenever possible and only fall back to the
aperture if absolutely necessary so, for example, all VRAM van be
mapped with things like prefetching and relaxed write ordering enabled.
> The solution seemed fairly easy - add a detach routine to machfb to
> restore the BUS_CNTL register (patch attached). However, this fails
> because wsdisplay0 attaches at machfb0, so we also need a detach routine
> for wsdisplay. As wsdisplay0 is the console, we have to force the detach,
> so it seemed reasonable to add an additional flag for that (wscons patch
> also attached). This works, and halt now returns to the OFW prompt.
Does sparcle's mach64 have 8MB VRAM? I've got an 8MB PGX64 to play with.
> However, I have a question about the wscons patch - there is no
> wsdisplay_noemul_detach(), so is it sensible to call only
> wsdisplay_emul_detach() on detach, or is there configuration where
> wsdisplay* at machfb could be wsdisplay_noemul?
Actually, we can probably leave the registers enabled anyway, and only
turn them off if something tries to mmap that last bit of video RAM.
IIRC machfb itself doesn't need VRAM access at all, and the whole song
& dance is mostly intended for X.
Main Index |
Thread Index |