hi folks. i've gotten native xorg building for ofppc, but my pegasosII isn't currently setup for testing. can anyone test this for me? i can either upload my sets or you can build your own, using the '-V X11FLAVOUR=Xorg -V MKX11=yes'. thanks! .mrg.
On Thu, 18 Nov 2010 20:29:01 +1100 matthew green <mrg <at> eterna.com.au> wrote: > i've gotten native xorg building for ofppc, but my pegasosII isn't > currently setup for testing. Very nice! :) > can anyone test this for me? i can either upload my sets or you can > build your own, using the '-V X11FLAVOUR=Xorg -V MKX11=yes'. Yes, I will do. Uploading your sets would be easiest for me. -- -- Frank Wille
> > i've gotten native xorg building for ofppc, but my pegasosII isn't > > currently setup for testing. > > Very nice! :) > > > can anyone test this for me? i can either upload my sets or you can > > build your own, using the '-V X11FLAVOUR=Xorg -V MKX11=yes'. > > Yes, I will do. Uploading your sets would be easiest for me. ok, please check out the sets in: ftp.netbsd.org:/pub/NetBSD/misc/mrg/ofppc-xorg-sets/ thanks! if it doesn't work, i'll see about getting my system setup. .mrg.
matthew green wrote:
>> > can anyone test this for me? i can either upload my sets or you can
>> > build your own, using the '-V X11FLAVOUR=Xorg -V MKX11=yes'.
>> [...]
> if it doesn't work, i'll see about getting my system setup.
It doesn't work. I can neither run "X -configure" nor start with a working
xorg.conf. I'm always getting a fatal server error:
Fatal server error:
xf86OpenConsole: No console driver found
Supported drivers:
Check your kernel's console driver configuration and /dev entries
There are no console drivers? Probably you forgot to define WSCONS_SUPPORT
somewhere?
--
--
Frank Wille
> >> > can anyone test this for me? i can either upload my sets or you can > >> > build your own, using the '-V X11FLAVOUR=Xorg -V MKX11=yes'. > >> [...] > > if it doesn't work, i'll see about getting my system setup. > > It doesn't work. I can neither run "X -configure" nor start with a working > xorg.conf. I'm always getting a fatal server error: > > Fatal server error: > xf86OpenConsole: No console driver found > Supported drivers: > Check your kernel's console driver configuration and /dev entries > > There are no console drivers? Probably you forgot to define WSCONS_SUPPORT > somewhere? i got around to testing this myself. i have a problem with X -configure doesn't work because it tries to enable IO access via xf86EnableIO() and the PCI_MAGIC_IO_RANGE code (ppc_video.c) but the screxf86Info.screenFd is set to -1 so it doesn't work: [ 333.725] (WW) xf86EnableIO -1 [ 333.725] (II) xf86EnableIO: ffffffff [ 333.726] (WW) Can't map IO space! [ 333.728] (WW) Falling back to old probe method for wsfb but the old probe method doesn't do anything. mac? any ideas off hand?(Continue reading)
did the old xfree 4.x ever work for X on ofppc? i don't see an X binary... if so, i guess i should just convert ofppc now, and we can fix the bugs more easily without having to share sets, etc. .mrg.
On Sun, 05 Dec 2010 09:36:51 +1100 matthew green <mrg <at> eterna.com.au> wrote: > did the old xfree 4.x ever work for X on ofppc? Yes, definitely. It worked fine on my Pegasos. > i don't see an X binary... I see it in the last xserver.tgz releases. > if so, i guess i should just convert ofppc now, and we can fix > the bugs more easily without having to share sets, etc. Please do it. We have to fix those bugs anyway. -- -- Frank Wille
On Thu, 02 Dec 2010 22:38:59 +1100 matthew green <mrg <at> eterna.com.au> wrote: > i got around to testing this myself. i have a problem with X -configure > doesn't work because it tries to enable IO access via xf86EnableIO() > and the PCI_MAGIC_IO_RANGE code (ppc_video.c) but the > screxf86Info.screenFd is set to -1 so it doesn't work: > > [ 333.725] (WW) xf86EnableIO -1 > [ 333.725] (II) xf86EnableIO: ffffffff > [ 333.726] (WW) Can't map IO space! > [ 333.728] (WW) Falling back to old probe method for wsfb > > but the old probe method doesn't do anything. > > > mac? any ideas off hand? I doubt that he reads port-ofppc. I have put him into CC. -- -- Frank Wille
Moin, On Dec 4, 2010, at 7:11 PM, Frank Wille wrote: > On Thu, 02 Dec 2010 22:38:59 +1100 > matthew green <mrg <at> eterna.com.au> wrote: > >> i got around to testing this myself. i have a problem with X - >> configure >> doesn't work because it tries to enable IO access via xf86EnableIO() >> and the PCI_MAGIC_IO_RANGE code (ppc_video.c) but the >> screxf86Info.screenFd is set to -1 so it doesn't work: >> >> [ 333.725] (WW) xf86EnableIO -1 >> [ 333.725] (II) xf86EnableIO: ffffffff >> [ 333.726] (WW) Can't map IO space! screenFd should be a handle to ttyE0, used earlier to ioctl(WSDISPLAYIO_SMODE, WSDISPLAYIO_MODE_MAPPED) and such. In doubt do what macppc does. >> [ 333.728] (WW) Falling back to old probe method for wsfb >> >> but the old probe method doesn't do anything. That would cause more trouble than anything else since there is no way to tell if whatever wsfb wants to use has already been claimed by another driver via PCI or whatever.(Continue reading)
> > On Thu, 02 Dec 2010 22:38:59 +1100 > > matthew green <mrg <at> eterna.com.au> wrote: > > > >> i got around to testing this myself. i have a problem with X - > >> configure > >> doesn't work because it tries to enable IO access via xf86EnableIO() > >> and the PCI_MAGIC_IO_RANGE code (ppc_video.c) but the > >> screxf86Info.screenFd is set to -1 so it doesn't work: > >> > >> [ 333.725] (WW) xf86EnableIO -1 > >> [ 333.725] (II) xf86EnableIO: ffffffff > >> [ 333.726] (WW) Can't map IO space! > > screenFd should be a handle to ttyE0, used earlier to > ioctl(WSDISPLAYIO_SMODE, WSDISPLAYIO_MODE_MAPPED) and such. In doubt > do what macppc does. it isn't setup during X -configure for ofppc. > > I doubt that he reads port-ofppc. I have put him into CC. thanks frank! > Indeed I don't ;) no wonder you were ignoring me ;) i tried with an xorg.conf and it started up, but with an 800x600 display. it also has the same problem above:(Continue reading)
Hello, On Dec 5, 2010, at 4:35 AM, matthew green wrote: > >>> On Thu, 02 Dec 2010 22:38:59 +1100 >>> matthew green <mrg <at> eterna.com.au> wrote: >>> >>>> i got around to testing this myself. i have a problem with X - >>>> configure >>>> doesn't work because it tries to enable IO access via >>>> xf86EnableIO() >>>> and the PCI_MAGIC_IO_RANGE code (ppc_video.c) but the >>>> screxf86Info.screenFd is set to -1 so it doesn't work: >>>> >>>> [ 333.725] (WW) xf86EnableIO -1 >>>> [ 333.725] (II) xf86EnableIO: ffffffff >>>> [ 333.726] (WW) Can't map IO space! >> >> screenFd should be a handle to ttyE0, used earlier to >> ioctl(WSDISPLAYIO_SMODE, WSDISPLAYIO_MODE_MAPPED) and such. In doubt >> do what macppc does. > > it isn't setup during X -configure for ofppc. As I said, wsfb can't be probed in a sane way. As for the other drivers - for most of those which use the old probe method won't do anything because the API calls they use to find their hardware are broken now. The new method is exclusively for PCI, we can't convert(Continue reading)
> > [ 153.944] (WW) xf86EnableIO -1 > > [ 153.945] (II) xf86EnableIO: ffffffff > > [ 153.945] (WW) Can't map IO space! > > > > even in this case, but it doesn't seem to truly break it. > > Depends on the graphics driver - if it tries to do anything PIO, like > accessing the legacy VGA registers, it will bork. Since wsfb doesn't > know about those you're safe for now. If you're trying to use anything > not from ATI ( even the mach64 has everything available via MMIO ) > you'll probably run into problems, and especially older chips tend to > have only the drawing engine in MMIO registers and mode setup in > extended VGA registers. it is still broken. it comes up in only 800x600 and the colours are wrong. i'm not sure how to describe it. the 800x600 seems to be somewhat 'expected' given this autoconfig: genfb0 at pci0 dev 8 function 0: ATI Technologies Radeon 9200PRO 5960 genfb0: framebuffer at 0xc0000000, size 800x600, depth 8, stride 800 wsdisplay0 at genfb0 kbdmux 1: console (default, vt100 emulation) wsmux1: connecting to wsdisplay0 drm at genfb0 not configured > > i'm going to switch ofppc to xorg by default... and we'll fix these > > issues. > > I'm still trying to figure out what exactly broke X -configure :/(Continue reading)
Hello, On Dec 5, 2010, at 9:22 PM, matthew green wrote: > it is still broken. it comes up in only 800x600 and the colours > are wrong. i'm not sure how to describe it. the 800x600 seems > to be somewhat 'expected' given this autoconfig: > > genfb0 at pci0 dev 8 function 0: ATI Technologies Radeon 9200PRO 5960 > genfb0: framebuffer at 0xc0000000, size 800x600, depth 8, stride 800 > wsdisplay0 at genfb0 kbdmux 1: console (default, vt100 emulation) > wsmux1: connecting to wsdisplay0 > drm at genfb0 not configured Genfb relies on a callback to set palette registers - if OF on your machine doesn't do that right ( or the callback isn't there or whatever ) it can't do anything about it. >>> i'm going to switch ofppc to xorg by default... and we'll fix these >>> issues. >> >> I'm still trying to figure out what exactly broke X -configure :/ > > well, xf86-video-wsfb fails to do PROBE_DETECT which is what > X -configure uses. It never did anything else. > but i have a ati 9200 card, and i was kind of expecting to be able(Continue reading)
Michael wrote: > On Dec 5, 2010, at 9:22 PM, matthew green wrote: > >> it is still broken. it comes up in only 800x600 and the colours >> are wrong. i'm not sure how to describe it. the 800x600 seems >> to be somewhat 'expected' given this autoconfig: >> >> genfb0 at pci0 dev 8 function 0: ATI Technologies Radeon 9200PRO 5960 >> genfb0: framebuffer at 0xc0000000, size 800x600, depth 8, stride 800 On the Pegasos you can choose a different resolution in OF by defining the words "screen-width" and "screen-height". For example: 1024 to screen-width 768 to screen-height > Genfb relies on a callback to set palette registers - if OF on your > machine doesn't do that right ( or the callback isn't there or > whatever ) it can't do anything about it. There seem to be no colour commands in SmartFirmware. >> "pcictl list" doesn't show it, either. i'd expect to see it on >> pci0, but it isn't: >> >> # dmesg|grep 'at pci0' >> pchb0 at pci0 dev 0 function 0 >> genfb0 at pci0 dev 8 function 0: ATI Technologies Radeon 9200PRO 5960 >> genfb1 at pci0 dev 8 function 1: ATI Technologies Radeon 9200 Pro(Continue reading)
Michael wrote: >> "pcictl list" doesn't show it, either. i'd expect to see it on >> pci0, but it isn't: >> >> # dmesg|grep 'at pci0' >> pchb0 at pci0 dev 0 function 0 >> genfb0 at pci0 dev 8 function 0: ATI Technologies Radeon 9200PRO 5960 >> genfb1 at pci0 dev 8 function 1: ATI Technologies Radeon 9200 Pro >> Secondary >> # pcictl pci0 list >> 000:00:0: Marvell MV6436x System Controller (host bridge, revision >> 0x03) > > This is weird - if pcictl can't see it then neither can libpciaccess, > all it does is walk over /dev/pci* nodes. You can't really blame Xorg > for that. Indeed, that's a bug in ofppc/pci/gt_mainbus.c (it worked with pegasospci before). The following patch fixes that. I will committ the patch as soon as kiyohara <at> , who wrote this file, gives his ok (or doesn't object). Index: gt_mainbus.c =================================================================== RCS file: /cvsroot/src/sys/arch/ofppc/pci/gt_mainbus.c,v retrieving revision 1.2 diff -u -r1.2 gt_mainbus.c --- gt_mainbus.c 20 Jun 2010 00:25:41 -0000 1.2 +++ gt_mainbus.c 11 Dec 2010 16:30:53 -0000 <at> <at> -49,6 +49,7 <at> <at>(Continue reading)
matthew green wrote: > frank, could you explain what this patch is doing? or more exactly, > why? what's with the AGP enablement? I'm not sure about the technical details, but I guess that you have to switch the Marvell controller into AGP-mode to be able to access AGP-cards on the PCI bus. The Pegasos2 has no real AGP bus, it is somehow... emulated? By writing 0x08000000 to GT_GPP_Value_Set the configuration space of AGP cards becomes visible. Writing the same value to GP_GPP_Value_Clear makes them disappear again. The problem in the original source was that the AGP configuration space was only enabled during autoconfig. So every PCI bus scan after that was unable to see AGP cards. -- -- Frank Wille
> matthew green wrote: > > > frank, could you explain what this patch is doing? or more exactly, > > why? what's with the AGP enablement? > > I'm not sure about the technical details, but I guess that you have to > switch the Marvell controller into AGP-mode to be able to access AGP-cards > on the PCI bus. The Pegasos2 has no real AGP bus, it is somehow... > emulated? > > By writing 0x08000000 to GT_GPP_Value_Set the configuration space of AGP > cards becomes visible. Writing the same value to GP_GPP_Value_Clear makes > them disappear again. > > The problem in the original source was that the AGP configuration space was > only enabled during autoconfig. So every PCI bus scan after that was unable > to see AGP cards. OK. is there a reason to swap it on and off just for pci conf reads? .mrg.
On Mon, 13 Dec 2010 00:02:37 +1100 matthew green <mrg <at> eterna.com.au> wrote: > > The problem in the original source was that the AGP configuration space > > was only enabled during autoconfig. So every PCI bus scan after that > > was unable to see AGP cards. > > OK. is there a reason to swap it on and off just for pci conf reads? The only reason at the moment is that the old pegasospci-approach did it the same way, and that it works. We should just try what happens when switching it on during gt_attach() and leave it so. I can test that durig the next days. -- -- Frank Wille
matthew green wrote: >> [...] >> The problem in the original source was that the AGP configuration >> space was only enabled during autoconfig. So every PCI bus scan after >> that was unable to see AGP cards. > > OK. is there a reason to swap it on and off just for pci conf reads? I tested it now with keeping the GPIO for AGP access enabled all the time. Seems to work. So this might be the better solution. -- -- Frank Wille
> Indeed, that's a bug in ofppc/pci/gt_mainbus.c (it worked with pegasospci > before). The following patch fixes that. I will committ the patch as soon > as kiyohara <at> , who wrote this file, gives his ok (or doesn't object). > > Index: gt_mainbus.c [ ... ] with this patch applied (by hand -- the spacing is really broken in your patch) my pegasos is able to use the "radeon" driver with Xorg. this is great! .mrg.
matthew gree wrote: > with this patch applied (by hand -- the spacing is really broken in > your patch) Sorry. My mail client does that. And I forgot if attachments make it into this list. > my pegasos is able to use the "radeon" driver with Xorg. Great! So you can commit Xorg for ofppc? I will try it then. Unfortunately the Pegasos2 still freezes with USB devices plugged in. I have no idea about this bug yet... -- -- Frank Wille
> > my pegasos is able to use the "radeon" driver with Xorg. > > Great! So you can commit Xorg for ofppc? I will try it then. > > Unfortunately the Pegasos2 still freezes with USB devices plugged in. I have > no idea about this bug yet... i flipped the switched a week or so ago -- any recent build with your fix should now work. .mrg.
RSS Feed
