Re: machfb MMIO versus SPARCle OFW
Hello, On Mon, 21 Oct 2013 21:09:04 +0100 Julian Coleman j...@coris.org.uk wrote: I tracked down why my SPARCle (SPARC laptop) appears to lock up on halt. The cause is: http://mail-index.NetBSD.org/source-changes/2012/08/15/msg036624.html 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 it. ( 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. have fun Michael
Re: machfb MMIO versus SPARCle OFW
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 it. Not sure why it causes the problem on SPARCle then. It has a Rage L Mobility, which I don't think is in any other machine that we use mach64 on (I had to add it to the match routine). Also, it's possible that the firmware is slightly different from the standard Sun version. Does sparcle's mach64 have 8MB VRAM? I've got an 8MB PGX64 to play with. Yes. dmesg is: machfb0 at pci0 dev 19 function 0: ATI Technologies Rage L Mobility (PCI) (rev. 0x64) machfb0: using MMIO aperture machfb0: 16 MB aperture at 0x0300, 4 KB registers at 0xa000 machfb0: 128 KB ROM at 0x0002 machfb0: 8192 KB SDRAM 55.815 MHz, maximum RAMDAC clock 230 MHz machfb0: initial resolution 1400x1050 at 8 bpp machfb0: attached to /dev/fb0 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. Not altering the BUS_CNTL register would seem easier. However, detach does work if that's not possible. Thanks, J -- My other computer also runs NetBSD/Sailing at Newbiggin http://www.netbsd.org// http://www.newbigginsailingclub.org/
Re: machfb MMIO versus SPARCle OFW
On Tue, 22 Oct 2013 11:50:43 +0100 Julian Coleman j...@coris.org.uk wrote: 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 it. Not sure why it causes the problem on SPARCle then. It has a Rage L Mobility, which I don't think is in any other machine that we use mach64 on (I had to add it to the match routine). Also, it's possible that the firmware is slightly different from the standard Sun version. Maybe the sparcle firmware uses the blitter. Most Sun and Apple firmware for PCI graphics chips I've seen runs the hardware as dumb framebuffers ( unlike for example SBus and UPA hardware ) but nothing keeps them from using it. Does sparcle's mach64 have 8MB VRAM? I've got an 8MB PGX64 to play with. Yes. dmesg is: machfb0 at pci0 dev 19 function 0: ATI Technologies Rage L Mobility (PCI) (rev. 0x64) machfb0: using MMIO aperture machfb0: 16 MB aperture at 0x0300, 4 KB registers at 0xa000 machfb0: 128 KB ROM at 0x0002 machfb0: 8192 KB SDRAM 55.815 MHz, maximum RAMDAC clock 230 MHz machfb0: initial resolution 1400x1050 at 8 bpp machfb0: attached to /dev/fb0 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. Not altering the BUS_CNTL register would seem easier. However, detach does work if that's not possible. Guess it's better to leave it alone then - X should know how to deal with it if needed ( and if there are problems then they need to be fixed on that side ) I'll dig up my PGX64. have fun Michael
re: machfb MMIO versus SPARCle OFW
Not altering the BUS_CNTL register would seem easier. However, detach does work if that's not possible. well -- this doesn't help ddb or dropping to the prom directly does it? i think a solution that leaves it working without any special detach needed is the best idea here. .mrg.
Re: machfb MMIO versus SPARCle OFW
Hi, well -- this doesn't help ddb or dropping to the prom directly does it? Strangely, droppping to DDB or to the PROM from DDB works fine. It's just halt and reboot that don't work. Thanks, J PS. I didn't test a kernel witout DDB. -- My other computer also runs NetBSD/Sailing at Newbiggin http://www.netbsd.org// http://www.newbigginsailingclub.org/
