RE: C+T 69030 driver on powerpc
Am now making some progress on the mangled graphics: When i have acceleration turned on, glyph drawing is a complete mess. it looks like the bits are being expanded backwards and characters are being read from the wrong place. I've gone through CPUToScreenColorExpandFill with a fine tooth comb, but can't see anything wrong, and all my MMIO_OUT32 writes into BRxx are correctly expanding into xf86WriteMmio32Le. Have you ever seen anything like this before? Thanks, Rob Taylor whoo! fixed! ok attached are my initial diffs, i'm gonna do soem work to clean this up, cos there are a number of ordering issues in the driver, so a bit of reorganization is probably in order (pun not intended...) ok 1st issue - cPtr-Bus was only getting set a long time after the 1st chipsMapMem, so changed logic here, also need to change this in a couple of other places also. 2nd issue - not sure if I'm right here, but it seems wrong to be using VIDMEM_MMIO_32BIT for vga register mapping.. taken a leaf from nv driver and mapped it as VIDMEM_MMIO | VIDMEM_READSIDEEFFECT. 3rd issue - VGAHWPTR(pScrn)-IOBase was being set before we'd registered the custom vga access functions, so was being read incorrectly. hence, even when my mapping was right, it was trying to read from the MDA ST01, rather than the CGA ST01. :D An issues I'm getting now, which I assume is endian-related is that my HWCursor is mangled (bytes the wrong way around) where do I tell the xserver how to draw into my words correctly? Thanks, Rob ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: C+T 69030 driver on powerpc
so I correct myself. looks like its nothing to do with the kernel framebuffer driver. it mroe to do with the state the card gets left in after being half configured *phew*!! so thats makes life a bit easier - i just need to fix the card configuration! This should not happen. It can only happen when the Xserver has the ROM BIOS mapped. Judging from your log that shouldn't happen. Can you find out where it happens? You can hardcode a test for the relevant PCI config space register and PCI tag in the appropriate PciWrite() function and call a function you can breakpoint from gdb. There are three functions for this purpose: xf86Break1/2/3(). Debugged! The mangling occurs when it trys and fails to map the ROM BIOS (and of course my embedded board doesnt have a rom bios..). Mangling occurs in handlePciBIOS, i'm afraid i'm not knowledgable enough about how this code should work to explain why, tho. It seems that when xf86ReadDomainMemory fails and it tries to restore the base register with if (savebase) pciWriteLong(Tag, PCI_MAP_REG_START + (b_reg 2),(CARD32) savebase); (where b_reg=0, savebase=0xfa00) the card doesnt like this and resets BASE0! (i.e. the line 'BASE0 0xfa00 addr 0xfa00 MEM' disappears from scanpci -v) odd. Luckily i can just work around this using NoINT10 :) Onwards! Rob Taylor Senior Developerrobt at flyingpig dot com Flying Pig Systems http://www.flyingpig.com Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: C+T 69030 driver on powerpc
Rob Taylor writes: Has anyone sucessfully run the chips 69030 driver on powerpc based systems? I'm trying to get it running on a custon 7410 based board with two 69030's on,a nd i;'m seing soem off things: my /proc/pci gives me that: Bus 0, device 18, function 0: VGA compatible controller: PCI device 102c:0c30 (Chips and Technologies) (rev 97). IRQ 18. Non-prefetchable 32 bit memory at 0xfa00 [0xfaff]. Bus 0, device 19, function 0: VGA compatible controller: PCI device 102c:0c30 (Chips and Technologies) (rev 97). IRQ 18. Non-prefetchable 32 bit memory at 0xfb00 [0xfbff]. at the moment i'm just attempting single head setup on device 18, however i find cPtr-PciInfo-memBase[0] is 0xff00 when calulating cPtr-FbAddress (in chipsPreInitHiQV) , rather than 0xfa00! Does any know any reason why xf86GetPciInfoForEntity would return incorrect information, or have i got the wrong end of the stick? well I now know why i get 0xff00 for the set up device - its MBASE0 is 0x000 when we do xf86scanpci, and PCINONSYSTEMCLASSES(baseclass, subclass) is true hence pciCheckForBrokenBase gets called, which will set MBASE0 to 0x, and as only the top byte is writable (16Meg chunks) MBASE0 becomes 0xff00. not that this seems to help me much. i'm just more confused now!! why on earth would mbase0 be 0, if its in use and /proc says the device's memory is at 0xfa0???! really just posting this here incase anyone else ever wants to know... =) Can you add some code to xf86scanpci() to find out why it's 0? On PPC PCI config space data gets obtained thru the kernel, therefore it is even harder to understand. Also could you please run 'scanpci -v'? Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: C+T 69030 driver on powerpc
Egbert Eich writes: Rob Taylor writes: Has anyone sucessfully run the chips 69030 driver on powerpc based systems? I'm trying to get it running on a custon 7410 based board with two 69030's on,a nd i;'m seing soem off things: my /proc/pci gives me that: Bus 0, device 18, function 0: VGA compatible controller: PCI device 102c:0c30 (Chips and Technologies) (rev 97). IRQ 18. Non-prefetchable 32 bit memory at 0xfa00 [0xfaff]. Bus 0, device 19, function 0: VGA compatible controller: PCI device 102c:0c30 (Chips and Technologies) (rev 97). IRQ 18. Non-prefetchable 32 bit memory at 0xfb00 [0xfbff]. at the moment i'm just attempting single head setup on device 18, however i find cPtr-PciInfo-memBase[0] is 0xff00 when calulating cPtr-FbAddress (in chipsPreInitHiQV) , rather than 0xfa00! Does any know any reason why xf86GetPciInfoForEntity would return incorrect information, or have i got the wrong end of the stick? well I now know why i get 0xff00 for the set up device - its MBASE0 is 0x000 when we do xf86scanpci, and PCINONSYSTEMCLASSES(baseclass, subclass) is true hence pciCheckForBrokenBase gets called, which will set MBASE0 to 0x, and as only the top byte is writable (16Meg chunks) MBASE0 becomes 0xff00. not that this seems to help me much. i'm just more confused now!! why on earth would mbase0 be 0, if its in use and /proc says the device's memory is at 0xfa0???! really just posting this here incase anyone else ever wants to know... =) Can you add some code to xf86scanpci() to find out why it's 0? On PPC PCI config space data gets obtained thru the kernel, therefore it is even harder to understand. Also could you please run 'scanpci -v'? In case you missed my previous mail, it appears that mbase0==0 is something to do with the as69030 kernel framebuffer driver i'm running. If i compile a kernel without fbdev, pci probing works fine. I've stepped though the failure case in xf86scanpci(). It's 0 because when we read the config space from the device into devp-cfgspc.dwords, we read 0 for the word corresponding to MBASE0, so defintly seems like some kind of hardware config level issue. Note that I have 2x69030's on this board, so perhaps intersting stuff happens because of that. i note that only the 1st device gets read as 0x, the second device gets correctly read as 0xfb00! One solution I'm considering is to use the framebuffer interface to mmap the device if the framebuffer driver is availiable, and using the current scheme if not. Unfortunatly I still get issues even with an non fbdev kernel. I think this is due to the fact that the big-endian hack (+0x80) only really works on a couple of HiQV chips. On the as69030, it uses 1st 8 Meg for Pipe A and 2nd 8 meg for Pipe B. There *is* a single pipe mode where it will put a byte swapped frame buffer at +0x80, but thats all (no registers), and obviously that isn't much use. So, I guess I'll be going though the driver and checking all its byte-swapping macros are properly in place, stripping out the +0x80 hack, and just telling X the correct pixel bit ordering! Make sense? Rob ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: C+T 69030 driver on powerpc
Rob Taylor writes: attached is 2 possible outputs of scanpci -v 1st is before running server 2nd is after! the server hangs waiting for a vertial retrace before reading ddc1, and needs to be SIGSEGV'd. the trace from the xserver, verbose 10 is also attached I had this happen to me too, once, however it turned out to be a HW failure. After I commented out this code I ran into other problems. You may comment out this code for testing, however one should try to understand why this code is causing problems. so I correct myself. looks like its nothing to do with the kernel framebuffer driver. it mroe to do with the state the card gets left in after being half configured *phew*!! so thats makes life a bit easier - i just need to fix the card configuration! This should not happen. It can only happen when the Xserver has the ROM BIOS mapped. Judging from your log that shouldn't happen. Can you find out where it happens? You can hardcode a test for the relevant PCI config space register and PCI tag in the appropriate PciWrite() function and call a function you can breakpoint from gdb. There are three functions for this purpose: xf86Break1/2/3(). Cheers, Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: C+T 69030 driver on powerpc
Tim Roberts writes: On Thu, 23 Oct 2003 17:16:19 +0100, Rob Taylor wrote: Has anyone sucessfully run the chips 69030 driver on powerpc based systems? I'm trying to get it running on a custon 7410 based board with two 69030's on,a nd i;'m seing soem off things: ... Also does anyone know the reason for the addition of 0x80 to the base address in the big-endian case? Many graphics chips include two separate views of the frame buffer: one that swaps bytes, one that does not. This makes it easy to handle endian mismatches. I'm guessing that's the case here. Right, that's exactly the reason for this. The BE support was tested for one of the HiQV chipsets - however I'm not sure if it was tested for the 69030. thanks for the info! google now tells me that Michael Stephen Hanni wrote the +0x8 hack for running ct65550 on his powerbook 3400 :) Currently theres a a lot of possibiliites as to what could be going wrong, so knowing whats right's a good place to start :) I'll try and get a well formed patch in when i get this all working (and I *will* get it working... *grr* ;)) noticed i forgot to mention the immediate symtoms in my last post - the driver starts up, the server gets to running, but there's no display, no change in output whatsover... We're running an fbdev driver for the card in the kernel, could i be seeing some sort of resorce allocation problem? We currently run an fbdev based driver in Xfree86 that works flawlessly but leaves a lot to be desired on the accelaration side, so hardware is all good. Thanks Rob Taylor Senior Developerrobt at flyingpig dot com Flying Pig Systems http://www.flyingpig.com Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
C+T 69030 driver on powerpc
Has anyone sucessfully run the chips 69030 driver on powerpc based systems? I'm trying to get it running on a custon 7410 based board with two 69030's on,a nd i;'m seing soem off things: my /proc/pci gives me that: Bus 0, device 18, function 0: VGA compatible controller: PCI device 102c:0c30 (Chips and Technologies) (rev 97). IRQ 18. Non-prefetchable 32 bit memory at 0xfa00 [0xfaff]. Bus 0, device 19, function 0: VGA compatible controller: PCI device 102c:0c30 (Chips and Technologies) (rev 97). IRQ 18. Non-prefetchable 32 bit memory at 0xfb00 [0xfbff]. at the moment i'm just attempting single head setup on device 18, however i find cPtr-PciInfo-memBase[0] is 0xff00 when calulating cPtr-FbAddress (in chipsPreInitHiQV) , rather than 0xfa00! Does any know any reason why xf86GetPciInfoForEntity would return incorrect information, or have i got the wrong end of the stick? Also does anyone know the reason for the addition of 0x80 to the base address in the big-endian case? Thanks to anyone who can spread some light on this for me! Rob Taylor Senior Developerrobt at flyingpig dot com Flying Pig Systems http://www.flyingpig.com Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: C+T 69030 driver on powerpc
On Thu, 23 Oct 2003 17:16:19 +0100, Rob Taylor wrote: Has anyone sucessfully run the chips 69030 driver on powerpc based systems? I'm trying to get it running on a custon 7410 based board with two 69030's on,a nd i;'m seing soem off things: ... Also does anyone know the reason for the addition of 0x80 to the base address in the big-endian case? Many graphics chips include two separate views of the frame buffer: one that swaps bytes, one that does not. This makes it easy to handle endian mismatches. I'm guessing that's the case here. -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: C+T 69030 driver on powerpc
Tim Roberts writes: On Thu, 23 Oct 2003 17:16:19 +0100, Rob Taylor wrote: Has anyone sucessfully run the chips 69030 driver on powerpc based systems? I'm trying to get it running on a custon 7410 based board with two 69030's on,a nd i;'m seing soem off things: ... Also does anyone know the reason for the addition of 0x80 to the base address in the big-endian case? Many graphics chips include two separate views of the frame buffer: one that swaps bytes, one that does not. This makes it easy to handle endian mismatches. I'm guessing that's the case here. Right, that's exactly the reason for this. The BE support was tested for one of the HiQV chipsets - however I'm not sure if it was tested for the 69030. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
