Re: rs480 + r300 driver fun..
Dave,
So I tested the (git from last night 5/10) the latest code
(x+mesa+drm) on my RS480
In general, things are MUCH better, but I was running through the
sample programs in Mesa, and I found some remaining issues. I ran the
tests on fglrx, took some screenshots, and compared them to the R300
results.
I've included the details below, but is bugzilla the best place to put
this info?
Cheers,
--Phil
I ran some of the Mesa samples in: '/progs/samples'
Visually Identical:
accum, blendeq, depth, star, stencil
Minor Problems:
line:
R300 is not pixel identical to fglrx, but they generally look the same.
nurb:
R300 is not pixel identical to fglrx, but they generally look the same.
olympic:
R300 is not pixel identical to fglrx, but they generally look the same.
bitmap1:
fgrlx seems broken.. 'GL' is not shown in the middle.
tri:
R300 is not pixel identical to fglrx, but they generally look the same.
I did notice that in the R300 version, the color gradient inside box
starts a line below the fglrx version.
I did get this warning:
*WARN_ONCE*
File r300_render.c function r300Fallback line 494
Software fallback:ctx-Line.StippleFlag
***
Major Problems:
logo:
It appears as if the clip plane is completely different, but the
basic geomtery is the same.
point:
On the R300 version, The crosshairs is one pixel lower.
prim:
On the R300 version, The openGL crossharis is one pixel lower
fogtest:
On the R300 version, the end of the tube is not red.
(In the source, the only thing that is red is:
static float back_mat_diffuse[] = {1.0, 0.0, 0.0, 1.0};
glMaterialfv(GL_BACK, GL_DIFFUSE, back_mat_diffuse); )
quad:
On the R300 version, the interior of the cone is not green.
sphere:
On the R300 version, the grid lines are missing, and there is a strip
missing on the cyclinder.
wave:
On the R300 version, the checkerboard is completely missing. If I
turn off lighting, the checkerboard appears.
progs/demos:
fire:
On the R300, the trees are corrupt... They're in front of the fire.
cubmap:
On the R300, This has a wierd corruption as it spins.
terrain:
On the R300, This has triangles flying everywhere. ;-)
ipers:
On the R300, Triangles intersect the main geometry.
tunnel:
On the R300, Triangles intersect the main geometry.
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Possible R300 Issues
Oliver Dave, You maybe have missed out on #dri-devel on freenode irc, it works reasonably well for getting insta-answers depending on timezone etc.. Ah. I HAVE missed that. I'll have to hang out there. I usually have the wireless network turned off when I'm X hacking, but this gives me a reason to fix that. Dave eventually got the RS480 working, (which is great, but frustrating that I couldn't have the rush... ;-) ) Hey 3D is still busted on the rs480, I've no idea when I'll get around to it, I'm sorta tipping away and the internals of r300 are not the nicest place to hack around in.. Alright. I've been playing with trying to get simple triangles to work with my 200M. (I've set hw_tcl to 0, and things still don't work properly.) My biggest obstacle is getting blob dumps that I can compare to what X is currently doing. I've tried revenge, but I am getting bogus results. I'm pretty sure that the problem is that I don't have the AGP apeture variable set properly. Oliver, what does that value represent? Is it the physical address of the ring buffer? In a system where the ring buffer lives in GART addressible memory, wouldn't you basically need to reimplement the GART in software? (Because there is no single address range which represents the entire ring buffer... It is a series of pages...) If the ring buffer lives in the framebuffer, things are much easier.. ... Also, I've tried glxtest, but the indirect buffer has NO match in the maps.log file. Dave, how did you generate this file? (Was it from an indirect buffer?) http://www.skynet.ie/~airlied/dri/mypa.parsed I downloaded glxtest from sourceforge/r300. Is there a more updated version that works? Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG Cheers, --Phil - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Possible R300 Issues
Oliver,
On 4/26/07, Oliver McFadden [EMAIL PROTECTED] wrote:
Currently this is hard-coded, because I haven't done dynamic calculation of
those variables yet.
You can determine REG_ADDR from lspci -v; you want the line that matches
(32-bit, non-prefetchable) [size=64K]. In the following example, REG_ADDR
would be 0xe500. I haven't figured out how to calculate REG_SIZE yet; It's
just copied from IBA.
...
Yeah. That one was easy enought to find. I changed that yesterday.
(I know it is working because it is getting the proper register values
when it reads things.)
You can determine AGP_ADDR and AGP_SIZE from dmesg | grep 'AGP aperture'.
agpgart: AGP aperture is 64M @ 0xe000
This is pcie card, so I don't have that string. What does that
address represent? Is it the address of the GART memory mapped into
the card? (Ie, the card accesses 0xe000, but it might actually be
mapped to some number of physical pages...)
For my card, I don't think that there is a region in memory (that I
can get to from the CPU) that matches that memory region as the card
sees it.
However, I CAN get access to the GART table, and use that to figure
out exactly where all of the ring buffer is mapped into physical
memory.
For example, the card sees my RING buffer as starting at 0x5800.
0x5800 is ALSO the start of the GART mapped addresses. So, the
first 4k of the ring buffer is located at the address of the page in
the first entry of the GART table.
If I need to access 4k-8k, I have to look at the second table entry
and map that page, etc.
I think that I can extend your tool to do that, but it will definately
make things more ugly than
the current map a range of memory.
Is it the physical address of the ring buffer? In a system where the
ring buffer lives in GART addressible memory, wouldn't you basically
need to reimplement the GART in software? (Because there is no single
address range which represents the entire ring buffer... It is a
series of pages...) If the ring buffer lives in the framebuffer,
things are much easier..
...
Also, I've tried glxtest, but the indirect buffer has NO match in the
maps.log file.
Dave, how did you generate this file? (Was it from an indirect buffer?)
http://www.skynet.ie/~airlied/dri/mypa.parsed
That appears to be a dump of an indirect buffer, parsed with
pretty_print_command_stream.tcl. Currently that program is able to parse the
indirect buffers better than my tool, as it can print register names in human
readable format, but this is a high priority on my TODO list too.
If you want to use pretty_print_command_stream.tcl you must feed it the
indirect
buffer in hexadecimal format, one value per line, with no 0x prefix.
deadbeef
deadbeef
deadbeef
...
Alright, I actually have glxtest decoding one of the command streams.
At some point, it gives me a pointer to an indirect buffer. However,
I have NO idea where that indirect
pointer refers to. (I have 8 other map files will many k of data...)
The README of glxtest says that you should look into the maps.log
file in order to find where the indirect buffere is mapped.
I was wondering how Dave found the indirect buffer to do the decoding.
If you want revenge to dump in this format, you would have to modify
analyze.c:analyze_indirect_buffer.
Change the following line.
analyze_packets (0, ib_size, ib_mapped_addr);
To.
int i;
for (i = 0; i ib_size; i++)
{
printf (%80lx\n, ib_mapped_addr[i]);
}
I downloaded glxtest from sourceforge/r300. Is there a more updated
version that works?
It should work, but a lot of the R300 tools are very hard-coded, so sometimes
they require some work. I hope that my tool will become a lot easier to use
and
more dynamic.
I do have more work to do on it, though. I'd like to hear feedback, too. :)
Any
wanted features, bugs, annoyances, etc.
Ok, will do Oliver. Thanks for the help.
--Phil
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: rs480 + r300 driver fun..
On 4/9/07, Zoltan Boszormenyi [EMAIL PROTECTED] wrote: Hi, Dave Airlie írta: Okay the GART is working fine on the rs480 from my branch, however the Congrats! r300 driver causes a chip lockup, I've loaded fglrx and from what I can see it disables the Vertex Shaders in hw and does that bit of the pipeline in sw.. at least on the system I have... If anyone else has an xpress 200 or 200m, perhaps they could try fglrx and run a GL app and find out what the value in reg 0x2140 is, the latest version of radeontool from my git repo will do it..[1] radeontool regmatch SE_CNTL_STATUS Before running glxgears, it gives 0x. During and after: 0x0100. I see the exact same results on my Radeon 200M: ( 01:05.0 VGA compatible controller: ATI Technologies Inc ATI Radeon XPRESS 200M 5955 (PCIE) (prog-if 00 [VGA]) ) I have to get the latest and greatest X/ati/Mesa to try drirc hack. Cheers, --Phil - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: rs480 + r300 driver fun..
Dave Roland, On 4/9/07, Roland Scheidegger [EMAIL PROTECTED] wrote: Dave Airlie wrote: Okay the GART is working fine on the rs480 from my branch, Congratulations on getting it to work. I've tested your DRM branch on my HP laptop with a 200M, and it works. (128M of video RAM, 0 sideport RAM.) X starts up with a nice stipple pattern, and gears hangs in the same way you described in your blog. (Damn. I was so close, I had 4 or 5 proper startups with my hacked/reverse engineered code, but I couldn't figure out how to make it happen reliably. I didn't read RADEON_IGPGART_UNK_38 before I wrote it.. Maybe that was the problem.) BTW. Base on the back traces I gathered when running kmmio, I think that the following defines should be renamed: RADEON_IGPGART_UNK_2E - RADEON_IGPGART_FLUSH RADEON_IGPGART_UNK_38 - RADEON_IGPGART_ENABLE (More details at: http://dri.freedesktop.org/wiki/Radeon200M) however the r300 driver causes a chip lockup, I've loaded fglrx and from what I can see it disables the Vertex Shaders in hw and does that bit of the pipeline in sw.. at least on the system I have... If anyone else has an xpress 200 or 200m, perhaps they could try fglrx and run a GL app and find out what the value in reg 0x2140 is, the latest version of radeontool from my git repo will do it..[1] radeontool regmatch SE_CNTL_STATUS I'll check out that register tonight. I think the bit that turns on/off the Vertex stuff is the same bit that used to turn on/off the TCL engine.. I'm not sure how we can handle this in r300, we probably need to use a swtcl path for these chips Dave. I thought the r300 driver could already handle tcl fallbacks. It's not news that the xpress chips don't have any hw tcl/vertex shaders, that has been known forever and is afaik officially confirmed (the screen code doesn't set the RADEON_CHIPSET_TCL bit for these chips for a reason). The same is still true for rs690, btw. Roland What has to be done now? Where can look to start hacking Mesa to support it? (I've spent all of my time so far in DRM.. (radeon_cp.c) ) Cheers, --Phil - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Testing the Radeon GART
Hi, Is there a simple way for me to test whether the GART is working on a radeon driver? I'm hacking the Radeon 200M, and I think that I've setup the GART properly. (unfortunately, the CP still doesn't work...) Is there a way for me to test if the memory is mapped in properly? Ideally, I would like some thing like the following: 1) Write Address Value to some radeon register. 2) Read the value back from the DRM module. 3) See that the written value matches the read value. 4) Rejoice. Cheers, --Phil - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Debugging the Radeon 200M command processor (CP)
Dave, On 3/4/07, Dave Airlie [EMAIL PROTECTED] wrote: Have you done this yet? I'd be interested in finding out how the entries in the table map to memory space.. there are two mappings types sso far, PCI and PCIE... PCI is just the bus addres, PCIE is bus address 8 | 0xc.. mayhaps we need another one.. I think that I figured the mapping. It is pretty simple: address in table = (bus_address 0xc); I dumped the GART table. From the card's point of view, I knew that the ring buffer was mapped at the beginning of the GART mappable pages. (The stuff that the GART maps was located at 0x5800, and that is where the ring buffer is located.) I figured out the virtual address of the ring buffer in the X server. I wrote a small kernel module to find the task (given a pid), and translate the user space virtual address to a physical address. (using get_user_pages). In a different experiment, I determined I figured out that for some reason whatever I write to the GART table gets endian swapped on read out. (If I write: 0x12345678, I read back: 0x78563412) (I use: ../mmapr/mmapr /dev/mem 0x33e8 64 | xxd -g4 ) Anyway, here are my results: Column 1: Physical addr of Xorg Ring Buf Column 2: GART table entries Column 3: Endian Corrected GART table entries 22e1f000 0cf0e122 22e1f00c 22e2 0c00e222 22e2000c 22e21000 0c10e222 22e2100c 22e22000 0c20e222 22e2200c 22e23000 0c30e222 22e2300c 22e24000 0c40e222 22e2400c 22e25000 0c50e222 22e2500c 22e26000 0c60e222 22e2600c So, if you compare the first and last column, you can see the equation is: address in table = (bus_address 0xc); I modified the gart code to allocate a table in RAM, and to write the addresses as you see above. Unfortunately, my cp STILL doesn't seem to work (I can't write to a scratch register and read it back..). I'm gonna run my kernel module on my hacked radeon driver, so that I am sure that what is written into the GART table matches the physical addresses of the ring buffer. (ie, I am writing the commands where the card is reading them.) That's for tonight. (I hope.) Cheers, --Phil - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Debugging the Radeon 200M command processor (CP)
On 3/12/07, Daniel Stone [EMAIL PROTECTED] wrote: On Mon, Mar 12, 2007 at 09:35:43AM -0400, Phillip Ezolt wrote: So, if you compare the first and last column, you can see the equation is: address in table = (bus_address 0xc); I modified the gart code to allocate a table in RAM, and to write the addresses as you see above. Unfortunately, my cp STILL doesn't seem to work (I can't write to a scratch register and read it back..). I'm gonna run my kernel module on my hacked radeon driver, so that I am sure that what is written into the GART table matches the physical addresses of the ring buffer. (ie, I am writing the commands where the card is reading them.) That's for tonight. (I hope.) Maybe it's something to do with the -- you might be more successful with 'bus_address | 0xc'. ;) Doh. That's actually a typo in the email. My code has the 'bus_address | 0xc'. Cheers, --Phil Cheers, Daniel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Debugging the Radeon 200M command processor (CP)
On 3/5/07, Phillip Ezolt [EMAIL PROTECTED] wrote: Dave, On 3/4/07, Dave Airlie [EMAIL PROTECTED] wrote: only enough to map 512k... (Also, the addresses are stored in big endian.. I think.) I might be interesting to actually look at what is in these addresses. That mght make sense on your card as you have actual RAM, the GART is allocated dynamically by fglrx, so if you use a 3D app I'd expect some of that RAM to start getting used for things.. Have you done this yet? I'd be interested in finding out how the entries in the table map to memory space.. there are two mappings types sso far, PCI and PCIE... PCI is just the bus addres, PCIE is bus address 8 | 0xc.. mayhaps we need another one.. Dave, Ok. I ran a 3-d app (nexuiz) and captured the state of the GART table at each point. Before: 000: 0cd0c931 0c503032 0c802732 0c302832 ...1.P02..'2.0(2 010: 0c702832 0c20d408 0cb05832 0cc0b40f .p(2. X2 0001cf0: 0cd01330 0c60be04 0cd0a736 0ce0010c ...0.`.6 0001d00: 0001d10: ... During: 000: 0cd0c931 0c503032 0c802732 0c302832 ...1.P02..'2.0(2 010: 0c702832 0c20d408 0cb05832 0cc0b40f .p(2. X2 ... 0001cf0: 0cd01330 0c60be04 0cd0a736 0ce0010c ...0.`.6 0001d00: 0cd0e715 0c00b30a 0c60e216 0c60c132 .`...`.2 0001d10: 0cf0092c 0cb02b36 0c503d31 0cf0e715 ...,..+6.P=1 ... 0002200: 0002210: After: 000: 0cd0c931 0c503032 0c802732 0c302832 ...1.P02..'2.0(2 010: 0c702832 0c20d408 0cb05832 0cc0b40f .p(2. X2 020: 0c50e508 0cb06e10 0ca07610 0cc0600c .Pn...v...`. 0001cf0: 0cd01330 0c60be04 0cd0a736 0ce0010c ...0.`.6 0001d00: 0c00 0c00 0c00 0c00 0001d10: 0c00 0c00 0c00 0c00 0001d20: 0c00 0c00 0c00 0c00 ... 00021f0: 0c00 0c00 0c00 0c00 0002200: 0002210: Interesting things to notice: 1) The amount of GART table which is used increases during the usage of the 3-D app. 2) The valid-looking table entries ends with zeros. My current guess is that that size of the table is ALWAYS the same, and is based on the following write: write32 27ff2000 at 14c - MC_AGP_LOCATION. If the entries are 0 (or 0x0c000) the card treats that entry as invalid. 3) After the 3-d app is run, some of the 0x0s are set to 0x0c000. So, probably the addresses are or'ed with 0xc at some point. I need one more piece of data to try to figure out how the mapping really takes place. I have: 1) The location of the ring buffer according to the card: (0x5800) 2) I have the virtual address of the ring buffer according to the X server. 3) Since, 0x5800 is the first address beyond the framebuffer, I am assuming that the first page of the ring buffer will be the first entry in the GART table. I just need to get the physical address of the first page of ring-buffer. (Given the X server virtual address...) Does anyone have any good ideas for that? (kgb is my current guess, but I would like to do something easier..) Once I have that address, I should be able to figure out how the physical address gets mangled and pushed into the GART table. BTW. Things DO seem to be written to the GART table in little endian order.. however, the read-out seems to reverse things. (Ie, if I write things to the table in big endian order, when I read it back it is flipped, and doesn't match what I wrote..) Cheers, --Phil Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied http://www.skynet.ie/%7Eairlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Debugging the Radeon 200M command processor (CP)
Dave, On 3/4/07, Dave Airlie [EMAIL PROTECTED] wrote: only enough to map 512k... (Also, the addresses are stored in big endian.. I think.) I might be interesting to actually look at what is in these addresses. That mght make sense on your card as you have actual RAM, the GART is allocated dynamically by fglrx, so if you use a 3D app I'd expect some of that RAM to start getting used for things.. Have you done this yet? I'd be interested in finding out how the entries in the table map to memory space.. there are two mappings types sso far, PCI and PCIE... PCI is just the bus addres, PCIE is bus address 8 | 0xc.. mayhaps we need another one.. Unfortunately, I too haven't been able to spend much time on this. One thing that I DID notice was that the number of valid entries DOES vary. I can't remember if I actually started a 3-D app, but I modified on eof the register dump stuff so that I could read the address of the GART table when the X server was running. (Rather than just through libsegfault). Once running, If I dumped the values at that address, it covered more than 512k. My previous (512k) dumps has been in the seconds following startup with no windows on the screen. I'll try running a 3-d tonight and see what happens. Here's another thing that I was going to try: FGLRX will dump the various physical addresses where it puts things. I was going to see how this mapps that what is in the GART table. That way we could probably figure out how to translate the address when they are put in the GART. Cheers, --Phil Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Debugging the Radeon 200M command processor (CP)
Dave, I turned on PC recording in kmmio. It reveals some interesting things about what those indirect memory accesses are doing. First, all of the calls to the 168/16C registers are in: MCIL_ModifyRegister (So it looks like this is the Memory Controller that it is accessing.) Next, I recorded the address of the function which called MCIL_ModifyRegister: read[18] - 0x1000 _ZN9GartRS48023InitializeGartRegistersEv write[118] - 0x1000 _ZN9GartRS48023InitializeGartRegistersEv write[138] - 0x0005 _ZN9GartRS48023InitializeGartRegistersEv read[2b] - 0x _ZN9GartRS48023InitializeGartRegistersEv write[12b] - 0x42040800 _ZN9GartRS48023InitializeGartRegistersEv write[12c] - 0x33b0 _ZN9GartRS48023InitializeGartRegistersEv read[39] - 0x0140 _ZN9GartRS48023InitializeGartRegistersEv write[139] - 0x0140 _ZN9GartRS48023InitializeGartRegistersEv read[38] - 0x0005 _ZN9GartRS48010EnableGartEv write[138] - 0x0005 _ZN9GartRS48010EnableGartEv read[2e] - 0x _ZN9GartRS48012flushGartTLBEv write[12e] - 0x0001 _ZN9GartRS48012flushGartTLBEv read[2e] - 0x _ZN9GartRS48012flushGartTLBEv write[12e] - 0x _ZN9GartRS48012flushGartTLBEv read[2e] - 0x _ZN9GartRS48012flushGartTLBEv write[12e] - 0x0001 _ZN9GartRS48012flushGartTLBEv read[2e] - 0x _ZN9GartRS48012flushGartTLBEv write[12e] - 0x _ZN9GartRS48012flushGartTLBEv So, some interesting things come out of this: I think that: 38/138 turns on the GART. 2e/12e flushs the Gart TLB 2c/12c The address of the GART table 2b/12b (?) 18/118 (?) 39/139 (?) I'll have to look at your dump and compare. (Maybe we can find some size differences). The only thing that is really peculiar, is that when I look at the GART table that 2c points to, it is MUCH too small.. Only 32*4 entries, which is only enough to map 512k... (Also, the addresses are stored in big endian.. I think.) I might be interesting to actually look at what is in these addresses. (BTW. I actually had to hack mmio so that it showed me the function who called MCIL_ModifyRegister. I hope to have full backtraces soon... ) --Phil On 2/21/07, Dave Airlie [EMAIL PROTECTED] wrote: Which would exactly fit between 0xCFFE - 0xCFFF. Yes this is an assumption, but some of the DRI code mentions that PCI express allocates the GART table at the end of the frame buffer, so that is why I was thinking it worked this way. Can you dump that memory area? see if it has a GART table in it.. GART tables usually are fairly easy to spot lots of page pointers.. Ok.. I read that file. None of them seem to touch the card directly.. The only bits that I found which actually touch the card are in radeon_cp.c (at least the older git checkout that I have...) ati_pcigart.c just creates the tables, the registers to poke are differrent depending on the type of gart.. When you say that the card reacts, are you referring to tickling these registers: RADEON_AIC_CNTL, RADEON_AIC_PT_BASE, RADEON_AIC_LO_ADDR, RADEON_AIC_HI_ADDR? (none of my fglrx traces (libsegfault or kmmio) touch these registers...) Yeah I just tried to see if a PCI GART worked, I didn't care if fglrx used it or not,... there is probably something else necessary outside the normal setup regs to get it to work I gave it up on it when it didn't work out of the box.. Dave. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Debugging the Radeon 200M command processor (CP)
Dave, On 2/21/07, Dave Airlie [EMAIL PROTECTED] wrote: Can you dump that memory area? see if it has a GART table in it.. GART tables usually are fairly easy to spot lots of page pointers.. Ok. More digging. It looks like the area from 0xCFFE - 0xCFFF is not the GART table. (./mmapr /dev/mem 0xCFFE 131072 | xxd -g4 ) Is see this: 000: a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 010: a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 020: a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 030: a5a5a5a5 a5a5a587 a5a5a5a5 a5a5a5a5 040: a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 050: a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 060: a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 However, if I look at the area that the writes to 16C revealed, I get something that looks like a GART table: (Using: mmapr /dev/mem 0x34b6 131072 | xxd -g4 gart_table) 000: 001031f1 002031f1 003031f1 004031f1 ..1.. [EMAIL PROTECTED] 010: 005031f1 006031f1 007031f1 008031f1 .P1..`1..p1...1. 020: 009031f1 00a031f1 00b031f1 00c031f1 ..1...1...1...1. 030: 00d031f1 00e031f1 00f031f1 32f1 ..1...1...1...2. ... 200: 210: However, look at how short it is? There are only 32*4 entries... That can't possibly be the whole thing... Maybe there are more entries somewhere else? Of this indirectly maps something else? Also, the accesses to 0x168/0x16C seem to have the following pattern: 1) Write to 0x168 (setup the index) (Where 0x100 indicates a write..) 2) Read/Write to/from 0x16C 3) Write 7f to 0x168 (Maybe a commit or something?) --Phil - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Debugging the Radeon 200M command processor (CP)
Nigel, On 2/21/07, Nigel Cunningham [EMAIL PROTECTED] wrote: Hi guys. I was wondering this morning, could it potentially help to dump the contents of the memory that fglrx allocates when the driver is suspended? I have a 200M as well (same 32MB config as you, Dave), and so could see what I got if it would have a hope of being helpful. I didn't even think about doing this. I don't know if it will be useful (or if I'll be able to grok it), but I'll take a look at it. If you can send me: 1) The Dump 2) Your procedure to generate it. Regards, Nigel Thanks for the offer, --Phil - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Debugging the Radeon 200M command processor (CP)
Dave, On 2/20/07, Dave Airlie [EMAIL PROTECTED] wrote: How is your card configured? No on-board RAM.. just UMA... 32MB setup by BIOS.. Hmm. Then our setup is a bit different. After looking at the debug output from the fglrx 8.32.5 driver, I think that there is a GART table at the end of the 128M. (From 0x57fe-0x5800) The CP is mapped at 0x5800. (In the GART space.) what makes you think that? I didn't think fglrx printed anything about the location of the GART table.. It doesn't, but I worked backwards. First, the frame buffer is from 0xc800 to 0xc. I turned on all of the debugging information, and fglrx printed out that it was allocating something from the framebuffer statring at the 'end of the freelist'. That it allocated this: ... [fglrx:firegl_aperture_alloc] alloc at end of free block... [fglrx:firegl_aperture_alloc] return slot 0xf62511e0 = page_index 31736 [fglrx:create_buffer_queue] UMM aperture page_index 31736 [fglrx:create_buffer_queue] ummslot=0xf62511e0 (physical_address=0x57bf8000) ... [fglrx:firegl_addmap] offset = 0xcfbf8000, size = 0x003e8000, type = 13 Is this particular case, the memory that was asked was _FIREGL_LFB_MEM at the alloc at end of free block. This was the first allocation from the end, and it from 0xCFBF8000-0xCFFE. So, there was something already at 0xCFFE - 0xCFFF, which I was assuming was the GART table. The fglrx driver says that there is a 128MB gart, so this would mean we need a table of size: num_pages = (128*1024*1024)/4096 = 32768 pages GART size = num_pages * (4 bytes per entry) = 131072 bytes or 0x2 bytes hex. Which would exactly fit between 0xCFFE - 0xCFFF. Yes this is an assumption, but some of the DRI code mentions that PCI express allocates the GART table at the end of the frame buffer, so that is why I was thinking it worked this way. Oh. That interesting... so when the driver uses the actual FB memory on the card it works. It really seems like the whole GART is the broken part. Why do you think that this card has a PCI gart (rather than a PCIe gart?) And is there any place that describes how a PCI gart should be setup on a Radeon? No this is just main RAM mapped by the BIOS setup the PCI gart registers on the card react to stimuli... the PCIE GART registers react to squat, ergo there are pieces of a PCI gart.. it is all described in ati_pcigart.c... Ok.. I read that file. None of them seem to touch the card directly.. The only bits that I found which actually touch the card are in radeon_cp.c (at least the older git checkout that I have...) When you say that the card reacts, are you referring to tickling these registers: RADEON_AIC_CNTL, RADEON_AIC_PT_BASE, RADEON_AIC_LO_ADDR, RADEON_AIC_HI_ADDR? (none of my fglrx traces (libsegfault or kmmio) touch these registers...) I wonder if our setups are different. In my case, I have my BIOS setup so that 0 mb of system ram is allocated, only the 128Mb of onboard video (sideport) memory is used. Now have a look at your RAM at that point with something, I normally do mmapr /dev/mem 0x34b4 256 | xxd -g4 you may need to change the byte order to something sensible.. 32-bit words might end in 0xc.. Ok. Cool. I'll check it out. What do those writes to 0x0168 and 0x16C do? If I knew I'd have it working, they are a bunch of indirect registers hiding behind index into 168 and data on 16c, I've just picked out the address from those, but nothing else is making major sense yet... therre may be a size or anything else in there.. Touche. I am learning ALL of this from scratch, so I never know which pieces of info are the common-knowledge, and which aren't. decoding as RADEON_CONFIG_APERSIZE 0x0400 [67108864] RADEON_CONFIG_APERSIZE: 0x400 0x0130 - 0x4080 decoding as RADEON_HOST_PATH_CNTL 0x4080 [1082130432] RADEON_HDP_APER_CNTL: 0x1 RADEON_HDP_SOFT_RESET: 0x0 RADEON_HDP_WC_TIMEOUT_28BCLK: 0x4 I still do that stuff in my head :-) It must be nice. ;-) Attached is my compressed kmmio trace from the 8.32.5 driver. (I also have a libsegfault trace, but it is much bigger Is there somewhere I can put it online? I don't think the wiki will let me upload a 9Meg file...) Well I've no major need for another trace, I have my own one :-), as I said I may/may not have time to keep looking at this... it is handy on the train in the morning with a laptop when I go to the office.. Dave. I selfishly hope your train runs slowly a few extra minutes each day. ;-) Cheers, --Phil - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV--
Re: Debugging the Radeon 200M command processor (CP)
Dave, On 1/15/07, Dave Airlie [EMAIL PROTECTED] wrote: ... I did a little more digging on this. It really looks like the address of ring.start is completely different than what is in RADEON_CP_RB_BASE. (I realize that ring.start is a virtual address and RADEON_CP_RB_BASE is a bus address. However, the drmAddMap call in RADEONDRIPciInit sets the address to 0, so I don't think it is setting 0x580 properly either...) In any event, I think that the radeon DRM module and the card have a completely different idea of where the ringbuffer is. (And as a result the card is executing crap) I'm off to find out how all of those mappings work... (I also am going to strace the fglrx driver to see how it sets them up...) I've looked at one of these laptops yesterday (thanks mjg59...) and I thought it might be possible to get PCI GART working on it, I didn't get it working, but I think it might be an initial method.. I'm hoping to get some time later in the week to look at it again.. Since you obviously understand how the GART fits in, I have some questions. ;-) I've been reading through code and googling, but I haven't been able to find a clear explanation about how you actually USE the gart. Are these the right steps for using a GART? 1) Allocate as many host pages as the GART can map. 2) Fill in the GART table with the physical addresses of the pages that you just allocated. 3) Tell the card the bus address of the GART table RADEON_WRITE(RADEON_AIC_PT_BASE, dev_priv-gart_info.bus_addr); 4) Tell the card about the lower/upper address of the vm which should be remapped. dev_priv-gart_vm_start (This is the same view of memory that the process has...) 5) Write stuff to dev_priv-gart_vm_start (from the process's point of view), and the graphics card will be able to retrieve it at the same address. (A simple explanation about the view of memory from the graphics card vs. the system would be helpful. I found the following, but I could use more details: http://lists.freedesktop.org/archives/xorg/2005-May/007673.html) NOTE:The fglrx 8.32.5 driver makes NO calls to the following registers (I have a 200M w/128M sideport and no UMA): RADEON_AIC_STAT,RADEON_AIC_PT_BASE,RADEON_AIC_TLB_ADDR, RADEON_AIC_TLB_DATA -or- RADEON_PCIE_TX_DISCARD_RD_ADDR_LO,RADEON_PCIE_TX_GART_BASE, RADEON_PCIE_TX_GART_START_LO,RADEON_PCIE_TX_GART_END_LO, RADEON_PCIE_TX_GART_CNTL, However, driver does set RADEON_CP_CSQ_CNTL to 0x8000, which is not defined anywhere that I've found... another quick hack method might be to place the CP in the reserved framebuffer memory (as it is all UMA) and see if that works In my BIOS, I've configured things so that I have no UMA memory and only 128MB of sideport. (If I turn on UMA, the 8.32.5 driver gets unstable...) Does this mean that I shouldn't be using the GART at all? The card expects the ring buffer to be at 0x5800.. (The FB begins at 0x5000... I think that this is a bus address..) How do I get that region mmaped into my virtual address space, so that the kernel can actually write commands to the proper location? Dave. Oh. BTW. I tried the 8.32.5 cp FW, and it doesn't change anything. Cheers, --Phil - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Debugging the Radeon 200M command processor (CP)
Roland, On 1/16/07, Roland Scheidegger [EMAIL PROTECTED] wrote: Phillip Ezolt wrote: (A simple explanation about the view of memory from the graphics card vs. the system would be helpful. I found the following, but I could use more details: http://lists.freedesktop.org/archives/xorg/2005-May/007673.html) NOTE:The fglrx 8.32.5 driver makes NO calls to the following registers (I have a 200M w/128M sideport and no UMA): RADEON_AIC_STAT,RADEON_AIC_PT_BASE,RADEON_AIC_TLB_ADDR, RADEON_AIC_TLB_DATA -or- RADEON_PCIE_TX_DISCARD_RD_ADDR_LO,RADEON_PCIE_TX_GART_BASE, RADEON_PCIE_TX_GART_START_LO,RADEON_PCIE_TX_GART_END_LO, RADEON_PCIE_TX_GART_CNTL, However, driver does set RADEON_CP_CSQ_CNTL to 0x8000, which is not defined anywhere that I've found... fglrx always writes a 0x8 there, even on old r200 based chips. Ok... I won't worry about it then. another quick hack method might be to place the CP in the reserved framebuffer memory (as it is all UMA) and see if that works In my BIOS, I've configured things so that I have no UMA memory and only 128MB of sideport. (If I turn on UMA, the 8.32.5 driver gets unstable...) Does this mean that I shouldn't be using the GART at all? The card expects the ring buffer to be at 0x5800.. (The FB begins at 0x5000... I think that this is a bus address..) How do I get that region mmaped into my virtual address space, so that the kernel can actually write commands to the proper location? Looks like the chip doesn't actually have neither pci nor pcie gart, (maybe pci gart but not used). This would be completely normal for a AGP based chip, does the driver write to RADEON_AGP_BASE? Roland No. It doesn't.. There are no reads or writes to 0x0170. However, if I read back the RADEON_AGP_BASE value when running fglrx is it set to: 0x5800. (I can't explain that...) Also, when I set the Xorg's RADEON_AGP_BASE value to: 0x5800 (rather than 0x), I am able to get the X server to startup. (Maybe Xorg clears this?) If it is 0: The Xserver just hangs waiting for the CP to be ready. (That's what's current in git..) If I set it to 0x5800: The Xserver starts up, the CP read/write pointers advance, but the commands don't actually get executed. Cheers, --Phil - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Debugging the Radeon 200M command processor (CP)
Jerome, On 1/13/07, Jerome Glisse [EMAIL PROTECTED] wrote: Is it something like this: BEGIN_RING(2); OUT_RING( CP_PACKET0( RADEON_SCRATCH_REG5, 0 ) );\ OUT_RING( 0xDEADBEEF); \ ADVANCE_RING() COMMIT_RING() Should be do the work, then you read the scratch reg via MMIO to see if the value was set. Alright, I tried that, but no luck. I was able to read and write the register using a MMIO, but when I wrote to the register with the CP, the value never showed up on in the register. (I waited for the cp to idle before I read it back.. I also read it a few seconds later..) However, the read pointer IS advancing, so the cp must be doing something. I suspect that it is just executing random commands. So, my current theory is that: 1) The CP is actually working. (Because the read pointer is advancing..) 2) The ring buffer instructions are not being written where the card is reading them from. (BTW. I suspected that the Microcode might not be loading properly, but I was able to read it back, and it matched what was written.) ... I did a little more digging on this. It really looks like the address of ring.start is completely different than what is in RADEON_CP_RB_BASE. (I realize that ring.start is a virtual address and RADEON_CP_RB_BASE is a bus address. However, the drmAddMap call in RADEONDRIPciInit sets the address to 0, so I don't think it is setting 0x580 properly either...) In any event, I think that the radeon DRM module and the card have a completely different idea of where the ringbuffer is. (And as a result the card is executing crap) I'm off to find out how all of those mappings work... (I also am going to strace the fglrx driver to see how it sets them up...) Does anyone know of any documents (other than: http://www.xfree86.org/current/DESIGN9.html) to help with understanding the mappings and how a GART/lack of GART would interact? I don't think there is any place for this except user account, you could send it to me and i will put it in mine. best, Jerome Glisse Ok. I have to fix a bug which causes some of the output to be incorrect. Once I fix it, I'll send it to you in a personal email. Cheers, --Phil - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Debugging the Radeon 200M command processor (CP)
Alex, On 1/15/07, Alex Deucher [EMAIL PROTECTED] wrote: On 1/15/07, Phillip Ezolt [EMAIL PROTECTED] wrote: Jerome, On 1/13/07, Jerome Glisse [EMAIL PROTECTED] wrote: Is it something like this: BEGIN_RING(2); OUT_RING( CP_PACKET0( RADEON_SCRATCH_REG5, 0 ) );\ OUT_RING( 0xDEADBEEF); \ ADVANCE_RING() COMMIT_RING() Should be do the work, then you read the scratch reg via MMIO to see if the value was set. Alright, I tried that, but no luck. I was able to read and write the register using a MMIO, but when I wrote to the register with the CP, the value never showed up on in the register. (I waited for the cp to idle before I read it back.. I also read it a few seconds later..) However, the read pointer IS advancing, so the cp must be doing something. I suspect that it is just executing random commands. So, my current theory is that: 1) The CP is actually working. (Because the read pointer is advancing..) 2) The ring buffer instructions are not being written where the card is reading them from. (BTW. I suspected that the Microcode might not be loading properly, but I was able to read it back, and it matched what was written.) ... The r300 microcode in the current drm may not work properly on XPRESS cards period. You might try again with the microcode you extract from fglrx or the windows driver. Updated microcode for some of the other cards may fix other problems. Perhaps it make sense to figure out what microcode fglrx loads on which cards. Alex Alright. This is easy enough for me to try. I can get the EXACT FW that the 8.32.5 driver uses for my card by running one of the dump routines that I have laying around. (After fglrx has started up.) BTW. I actually put the FW from a previous version of the driver (pre 8.32.5), and it didn't make a difference. However, I haven't tried it with the 8.32.5 version of fglrx... which works pretty well with this card. Thanks for the hint. I'll do it tonight. Cheers, --Phil - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Debugging the Radeon 200M command processor (CP)
Michel, On 1/12/07, Michel Dänzer [EMAIL PROTECTED] wrote: 4) Is there a simple command that I can issue to the CP to clear the screen JUST to see if it is issuing any commands from the ring buffer at all? You could do something along the lines of radeon_test_writeback: write to a scratch register via the CP and verify by reading the register directly. Actually, doing something like that from radeon_do_init_cp and returning an error if it fails might generally help to handle CP initialization issues more gracefully. Do you have any idea what that command stream would look like? Is it something like this: BEGIN_RING(2); OUT_RING( CP_PACKET0( RADEON_SCRATCH_REG5, 0 ) );\ OUT_RING( 0xDEADBEEF); \ ADVANCE_RING() COMMIT_RING() 1) The fglrx driver never sets the (RADEON_CP_RB_RPTR_ADDR) register. If I read the register back when fglrx is running, it is set to 0. What does that register indicate? You can ignore scratch register writeback for now. You may want to load the radeon kernel module with no_wb=1 though to prevent the unlikely event that it intervenes with anything. Ok. I'll try that. ... BTW. I have some code (based on bitfield) which automatically decodes the register traces from libsegfault, and gives me the names of the regs and the fields. It makes reading the trace much easier. Is there some place I can put that on the freedesktop servers? Cheers Thanks for the answers, --Phil - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 / R500 support and news
Jerome, I've put up some info about my Radeon 200M status: http://dri.freedesktop.org/wiki/Radeon200M I need to add more stuff, but it is a start. Cheers, --Phil On 1/11/07, Jerome Glisse [EMAIL PROTECTED] wrote: Hi all, I have setup a page on the DRI wiki: http://dri.freedesktop.org/wiki/R300 I have started to feed some informations in there and in the r300 to do list. But i think we really need people to give live to this wiki. So i encourage you to improve this. You could ask question on #dri-devel to me or any other people willing to enlight you on the status of a particular piece of code or feature. I will likely start another wiki page for R500 as soon as i figured more information about this. best, Jerome Glisse - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Debugging the Radeon 200M command processor (CP)
Hi All, I've been hacking away at the 200M driver without much success, and would like to hear if other people with more radeon experience can help me. I have things setup to use 128M of the sideport memory (and nothing else). I've been both userspace (libsegfault) and kernelspace (kmmio) register tracing to capture all of the accesses that the fglrx driver/library does to the card. ... There are many problems, but I want to start at the beginning. First, the stipple pattern doesn't appear on the screen when X starts up. As you may know, for radeon, this is done with DRI using indirect buffers to draw the stipple. Oddly, the pattern never shows up on my screen AND the indirect pointer (CP_IB_BASE) register is set to the value 0, so it doesn't look like the CP is even executing the command. (When the firglx runs for a while, this register is set to something sensible.. (0x5871) ) I tried to avoid the whole indirect buffer issue, so on every call to the indirect DRM ioctl, I issue the commands directly to the ring buffer and return. (I just copied the values which X wrote to the indirect buffer.) However, things still don't work correctly. CP --- 1) Could the CP be drawing this stuff, but putting it offscreen somewhere? 2) Could the command stream be wrong? 3) In the fgrlx 8.32.5 driver, the cp mode (RADEON_CP_CSQ_CNTL) is set to (0x8000), which doesn't correspond to ANY of the modes listed in the radeon_regs.h file. Does anyone have any idea what that value means? 4) Is there a simple command that I can issue to the CP to clear the screen JUST to see if it is issuing any commands from the ring buffer at all? Ring Buffer I'm beginning to suspect that the CP is just executing random commands, and I happen to get lucky that things start up at all. 1) The fglrx driver never sets the (RADEON_CP_RB_RPTR_ADDR) register. If I read the register back when fglrx is running, it is set to 0. What does that register indicate? GART 1) The fglrx driver also never sets ANY of the the pciexpress registers. (or any of the RADEON_AIC_*) Also, if I try to read the PCI Express registers when fglrx is running, the values are all set to zero. (Oddly, the PCIE index register: 0x0030 is written to, but it is never follwed by reads/write to 0x0034... However, the radeon_drv.h file also lists 0x0030 as the bus control register, so maybe it is using it as that. ) Is it possible that this card does use a GART? (Or is that crazy talk..) Thanks, --Phil - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Interest for PCI / PCIe tracing for Nouveau -project?
Stephane, What tools do you use for tracing? I know that you have the renouveau tool and libsegfault. I'm hacking on the ATI stuff, and it would be handy to have code which can just out what MMIO writes the kernel driver is doing. Do you guys have anything to do that? Cheers, --Phil On 12/27/06, Stephane Marchesin [EMAIL PROTECTED] wrote: Simen Thoresen wrote: Hi Nouveau- (and other cheap PCI and PCIe -graphics users) I have several PCI and PCIe tracers available through my employer, and will be able to purchase low-end versions of modern video-cards (preferably PCI versions, but possibly PCIe versions as well) for machines that will run both Windows and Linux. I'll probably have time to perform simple tests and grabs with these cards if I have something to look for. Please note that I am not a hardware (or software) developer, so I'll be learning to use the grabbers as we go along :-) Would any of you benefit from this? Hello, Thanks for your offer. That would surely be interesting, although it might generate huge logs. We have a number of tools that can achieve similar tasks (and which we can run at home, so as not to annoy someone else) , se we can probably get around it for now. However, PCI tracers are very useful when tracing weird bugs, so I might contact you at a later point. And if other nouveau devs are interested, I'll let them jump in :) Stephane - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ATI Xpress 200M Northbridge
Yeah, I've been swinging at it, but I haven't had much luck yet. I have one change which allows the X screen to come up, but hang after a few jiggles of the mouse cursor. .. I haven't got farther, but I haven't really had time to look at things this week anyway... The real problem is that we have no idea what sort of crazy programming needs to be done to properly setup card for 3D. I do have the FGLX 8.2.48driver working, so I have hope that the 200M can be supported in an open source driver. We need to figure out how FGLX is configuring the driver. I have some crazy ideas like running the Xorg in valgrind and catching all of the memory writes to the video registers. However, that still won't get me the setup which the DRM kernel module is doing. (NOTE: This trick might be usefull when trying to figure out how the card is issuing OpenGL commands, but there are other tricks that work for that, too. The best we can do for that is let the FGLRX setup the card, and then try to read the registers that might be important. After we have those values, we can try to figure out which the opensource driver is getting wrong. I have some scripts that pull some values, but I have no idea if they are the important ones or the ones that need to be changed. (Alternately, we could have someone disassemble/decompile the FGLRX DRM driver, write a spec, and then have somebody else properly implement a driver from the spec. Kinda like people did for the broadcom wireless card: http://bcm-specs.sipsolutions.net/ However, I don't want to do that myself as it might mean I couldn't submit the code to Xorg in the future.) Cheers, --Phil On 11/29/06, Erik Andrén [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jean-François Bucas skrev: Anybody knows where to look to find and help these others ? What needs to be done ? I've read about some registers that would be incorrects... You should drop Phillip Ezolt a line, as he has been trying to debug the issue. You can reach him thru this list or [EMAIL PROTECTED] Regards Erik Andrén Thanks [EMAIL PROTECTED] wrote: On 11/29/06, *simone.vianello86-at-tin.it http://simone.vianello86-at-tin.it simone.vianello86-at-tin.it http://simone.vianello86-at-tin.it |rivatv-devel|* ... mailto:... wrote: Hello, somebody know when the support for this hardware is available? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net mailto: Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel https://lists.sourceforge.net/lists/listinfo/dri-devel 2D support is already present. 3D support is just getting underway by some others, but it is not in a usable state so far as I know. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFbfkZN7qBt+4UG0ERAs2aAJ0Xq8iN4Ddqx7E0gOJhUHg3H7DbXgCeOINU dlVw/12V+giJXwUONkSx6qM= =TBrK -END PGP SIGNATURE- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
Re: ATI Radeon XPRESS 200M
Roland, On 11/21/06, Roland Scheidegger [EMAIL PROTECTED] wrote: Phillip Ezolt wrote: It does get recognized as PCI. However, I had to force it PCIE. (using OptionBusType PCIE). These cards are definately PCIE, so the original detection was wrong. I wonder if the MC_AGP_LOCATION register means something different on the 200M. These cards have an extra PCIE component which is supposed to shuffle graphics stuff to and from the memory. (This is in addition to the normal channels to and from the graphics card..) I'd be surprised if it's really different. I'd suspect that addresses within the AGP space just go untranslated to the bus without address translation as they did with other chips (with the chipset being responsible for translation). In any case, setting this up without RADEON_AGP_BASE likely makes little sense. I'm not sure why fglrx configures a 128MB window there. Maybe the chipset actually does some kind of agp gart remapping when set up correctly. Hmm. Maybe I just stumbled upon something good by accident. Like I said in the original email, there are still problems (garbage on the top half of the screen, and the hang). Should I read the value of RADEON_AGP_BASE when I have the working 8.24.8driver and try to set that as well in the DRM module? The hypermemory whitepaper gives more details: http://ati.amd.com/technology/HyperMemory_Whitepaper.pdf. Several people have said that Hypermemory is just a fancy algorithm to move from graphics card memory to main memory. From my reading of that white paper, there is actually more to it.. they have an auxiliary memory channel. It's hard to tell exactly what it is or how to control it. The paper has a fair amount of marketing speak, but look at the diagram on page 7.. And especially when they talk about the auxiliary memory channel. I'm not quite convinced this auxiliary memory channel really exists. Might be just the ability to access memory directly due to the pcie address remapper it has. Ok. That's what these slides seem to say: http://www.hothardware.com/viewarticle.aspx?page=2articleid=647 However, the whitepaper says: This PCI Express auxiliary memory channel is effectively a 64-bit memory channel with access to system memory. This means that a VPU equipped with a 64-bit local graphics memory bus and a PCI Express auxiliary memory channel has an effective 128-bit memory bus. So, it looks as if there is at least two channels out of the card when it has hypermemory. (Gee, ATI, specs would be nice..) You don't have a xpress200 with local ram (sideport), right? I think something strange is going on with that agp location stuff. My laptop has 128M of sideport memory, and I have the BIOS configured so there is 128M of sideport + 128M of UMA memory. (for a total of 256M). Interestingly, the fgrlx v8.24.8 driver (the one that works...), only detects 128M of memory. The fglrx v8.28.8 driver (which DOESN'T work... It hangs shortly after start up), detects 256M of memory, and has a different value for the MC_AGP_LOCATION. So, I'm guessing, that the v8.24.8 driver is probably exclusively using either the UMA or Sideport memory (and working correctly..). I don't know which (and I don't know how to figure it out... ;-) ) (I don't have access to the log files for these right now, but if you're interested, I can send them later tonight. ) Anyway. My Xorg.0.log is attached. It is a little chatty because I have RADEON_DEBUG enabled. (NOTE: There's one problem I know about.. I don't have r300_dri.so in the right place. However, having this missing shouldn't hang the box.) It's probably a good idea to NOT have it there for now - it's completely optional, xorg itself won't touch it (except aiglx). Ok. Cool. I won't worry about it then. Roland --Phil - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ATI Radeon XPRESS 200M
Alex, On 11/1/06, Alex Deucher [EMAIL PROTECTED] wrote: Sorry for the delay in response.No problem. I appreciate the responses. These are what the bits in the RBBM_STATUS register mean for r300(XPRESS may differ slightly)6:0Available slots in the FIFO 8Host Interface active 9CP request active10 FIFO request active 11 Host Interface retry active12 CP retry active13 FIFO retry active14 FIFO pipeline busy15 Event engine busy16 CP command stream busy17 2D engine busy18 2D portion of render backend busy 20 3D setup engine busy26 GA engine busy27 CBA 2D engine busy31 2D engine busy or 3D engine busy or FIFO not empty or CP busy orcommand stream queue not empty or Ring Buffer not empty Based on this information (which could be different for XPRESS),0x8001c100 means:host interface is activeFIFO pipeline busyEvent engine busyCP command stream busybit 31 - something is busy Good luck!AlexAlex, First, thanks for the clarification and help. Ok. I've made a small amount of progress. I figured out that the X server was treating the card as a PCI card rather than a PCIExpress card. I fixed that by forcing the bus type. (Option BusType PCIE). I've also tracked the CP hang down a little more. It hangs on the first use after radeon_do_init_cp has completed. So, rather than a particular bogus command, I suspect that this some sort of setup issue. I've turned on tracing like crazy (and added some of my own debugging), so maybe this can help:Initialization: [drm:radeon_do_init_cp] [drm:radeon_do_init_cp] dev_priv-cp_ring-handle f8bd1000 [drm:radeon_do_init_cp] dev_priv-ring_rptr-handle f8cd2000[drm:radeon_do_init_cp] dev-agp_buffer_map-handle f8cd3000[drm] Setting GART location based on new memory map[drm:radeon_do_init_cp] dev_priv-gart_size 8388608 [drm:radeon_do_init_cp] dev_priv-gart_vm_start 0x5800[drm:radeon_do_init_cp] dev_priv-gart_buffers_offset 0x58102000[drm:radeon_do_init_cp] Setting phys_pci_gart to f8bb 0FFF8000[drm:drm_ati_pcigart_init] PCI: Gart Table: VRAM 57FF8000 mapped at F8BB [drm:radeon_set_pciegart] programming pcie 5800 57FF8000 0080[drm:radeon_cp_load_microcode] [drm] radeon_do_wait_for_fifo 6: Succeeded![drm] radeon_do_wait_for_idle 6: Succeeded![drm] Loading R300 Microcode [drm:radeon_cp_init_ring_buffer] ring rptr: offset=0x33adf000 handle=0xf8cd2000[drm] radeon_do_wait_for_fifo 6: Succeeded![drm] radeon_do_wait_for_idle 6: Succeeded![drm:radeon_do_engine_reset] [drm:radeon_do_cp_reset] In radeon_do_cp_start:[drm] radeon_do_cp_start: About to COMMIT ring: radeon_status:RBBM_STATUS = 0x0140CP_RB_RTPR = 0xCP_RB_WTPR = 0xAIC_CNTL = 0x07e0 AIC_STAT = 0xAIC_PT_BASE = 0xTLB_ADDR = 0xTLB_DATA = 0x[drm] radeon_do_cp_start: Finished COMMIT ring: radeon_status:RBBM_STATUS = 0x80010140CP_RB_RTPR = 0x0006 CP_RB_WTPR = 0x0006AIC_CNTL = 0x07e0AIC_STAT = 0xAIC_PT_BASE = 0xTLB_ADDR = 0xTLB_DATA = 0xFor RBBM_STATUS = 0xXXX1, this means: bit 16: CP command stream busyAfter this, the CP command stream never reports a non-busy status. Ie, bit 16 (AND bit 31) is always set.Do you have any idea how the CP could go haywire? 0) What has to be setup properly for the CP work? (Or conversely, what, if setup improperly, could cause the CP to hang...)1) Could the ring buffer be mapped into a different location than we told the CP? (And the CP is executing some bogus/random commands..) (In particular, would this mean that the code in 'radeon_cp_init_ring_buffer' is wrong for this card? ) 2) Could the R300 FW that has been uploaded be the incorrect one for this card? (I noticed that radeon_do_cp_start is the first time the cp is fed commands after the FW is loaded. ) Is there a simple test to see if the CP is working? There are more problems later, but I think that this is the start of the badness.Thanks,--Phil - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ATI Radeon XPRESS 200M
Alex, (II) resource ranges after probing: DRI broken:[33] 00 0x03b0 - 0x03bb (0xc) IS[B][34] 00 0x03c0 - 0x03df (0x20) IS[B] ... fglrx:[34] 00 0xb01203b0 - 0xb01203bb (0xc) IS[B] [35] 00 0xb01203c0 - 0xb01203df (0x20) IS[B] 1) What are these mappings used for?Not sure.Possibly something for PCIE GART?What apertures does theXPRESS chip expose? How do I check that? Here's what lspci exposes: 01:05.0 VGA compatible controller: ATI Technologies Inc ATI Radeon XPRESS 200M 5955 (PCIE) (prog-if 00 [VGA]) Subsystem: Hewlett-Packard Company Unknown device 30a4 Flags: bus master, 66MHz, medium devsel, latency 66, IRQ 201 Memory at c000 (32-bit, prefetchable) [size=256M] I/O ports at 9000 [size=256] Memory at b010 (32-bit, non-prefetchable) [size=64K] [virtual] Expansion ROM at b012 [disabled] [size=128K] Capabilities: [50] Power Management version 2 3) What part of radeon probe would be responsible for adding these?RADEONMapMMIO() and RADEONMapFB() set up the register and FB maps andRADEONInitMemoryMap() and friends handle chip side stuff for the memory controller, etc.Ok. I'll check those out. I'm having a little difficultly figuring out what exactly these mappings mean. (So, this is just basic stuff..) Does it indicate where the various components of the graphics card are mapped into the Xorg server address space? (I've read http://ftp.x.org/pub/X11R6.9.0/doc/html/DESIGN9.html. It has details, but the not a high-level overview.) Sorry I can't be more helpful.AlexAs an aside, I figured out why the CPU time jumps to 100%. RADEONLoadCursorImage calls RADEONWaitForIdleCP and we loop infinitely in it. Since this calls into the kernel DRM module, I turned on debugging. The X server calls: drmCommandNone(info-drmFD, DRM_RADEON_CP_IDLE); Which then calls - [drm:radeon_cp_idle] - [drm:radeon_do_cp_idle] - [drm:radeon_do_wait_for_idle]This fails, returns back up the stack, and then the call happens again. ...So, the CPU is spinning waiting for the card to be idle. I turned on debugging so that I can see the status register. messages:Oct 26 23:53:57 localhost kernel: RBBM_STATUS = 0x80010140[Repeated 10 more times.] messages:Oct 26 23:54:03 localhost kernel: RBBM_STATUS = 0x88030140messages:Oct 26 23:54:03 localhost kernel: RBBM_STATUS = 0x8803613fmessages:Oct 26 23:54:04 localhost kernel: RBBM_STATUS = 0x88036139messages:Oct 26 23:54:04 localhost kernel: RBBM_STATUS = 0x88036133 messages:Oct 26 23:54:04 localhost kernel: RBBM_STATUS = 0x8803612dmessages:Oct 26 23:54:04 localhost kernel: RBBM_STATUS = 0x88036127messages:Oct 26 23:54:05 localhost kernel: RBBM_STATUS = 0x88036121messages:Oct 26 23:54:05 localhost kernel: RBBM_STATUS = 0x8803611b messages:Oct 26 23:54:05 localhost kernel: RBBM_STATUS = 0x88036115messages:Oct 26 23:54:06 localhost kernel: RBBM_STATUS = 0x8803610fmessages:Oct 26 23:54:06 localhost kernel: RBBM_STATUS = 0x88036109messages:Oct 26 23:54:06 localhost kernel: RBBM_STATUS = 0x88036103 messages:Oct 26 23:54:06 localhost kernel: RBBM_STATUS = 0x8001c100[Repeated forever..]I can see from the include that the 131 bit being set means that the card is active. I found a reference on the net which said that the other bits of the register actually tell WHAT part of the card is busy. However, I can't find any place that actually defines what they mean. What does a status of 0x8001c100 mean? (ie, what parts are busy? That might help me figure out what is misconfigured... ) (On the plus side, it actually looks like DRM is reading the proper memory for the status register. I can see the number of free FIFO entries decreasing...) Thanks,--PhilFWIW: Here's a full debug state when it gets stuck (These repeat, but the CP_RB_WTPR increases by 6. ): [drm:drm_ioctl] pid=2392, cmd=0x6444, nr=0x44, dev 0xe200, auth=1[drm:radeon_cp_idle] [drm:radeon_do_cp_idle] [drm:radeon_do_wait_for_fifo] *ERROR* failed!radeon_status:RBBM_STATUS = 0x8001c100 CP_RB_RTPR = 0x00f7CP_RB_WTPR = 0xa895AIC_CNTL = 0x07e1AIC_STAT = 0xAIC_PT_BASE = 0x35428000TLB_ADDR = 0xTLB_DATA = 0x[drm:drm_ioctl] ret = fff0 [drm:drm_ioctl] pid=2392, cmd=0x6444, nr=0x44, dev 0xe200, auth=1 [drm:radeon_cp_idle] [drm:radeon_do_cp_idle] [drm:radeon_do_wait_for_fifo] *ERROR* failed!radeon_status:RBBM_STATUS = 0x8001c100CP_RB_RTPR = 0x00f7CP_RB_WTPR = 0xa89bAIC_CNTL = 0x07e1 AIC_STAT = 0xAIC_PT_BASE = 0x35428000TLB_ADDR = 0xTLB_DATA = 0x[drm:drm_ioctl] ret = fff0[drm:drm_ioctl] pid=2392, cmd=0x6444, nr=0x44, dev 0xe200, auth=1[drm:radeon_cp_idle] [drm:radeon_do_cp_idle] [drm:radeon_do_wait_for_fifo] *ERROR* failed!radeon_status:RBBM_STATUS = 0x8001c100CP_RB_RTPR = 0x00f7CP_RB_WTPR = 0xa8a1AIC_CNTL = 0x07e1AIC_STAT = 0x AIC_PT_BASE = 0x35428000TLB_ADDR = 0xTLB_DATA = 0x[drm:drm_ioctl] ret = fff0 - Using Tomcat but need to do more?
Re: ATI Radeon XPRESS 200M
Alex, I was able to get the latest and greatest of everything compiled and limping. X starts up, and then proceeds to consume 100% of the CPU. I have a good debugging environment, so I'll be able to walk through it with gdb to figure out exactly what's causing the problem. Once it gets in this state, I can't kill the X server, and gdb can't attach to it. According to oprofile, all of the CPU time is being spent in the kernel on the delay_pmtmr function. So it is appears as if we are in the kernel waiting for something. (As an ASIDE, I spent a bunch of time tracing down a stupid kernel panic. If DRM_MEMORY_DEBUG is defined for the DRM module, drm_ioremap is completely broken... It will call itself, and eventually cause a panic. ) Let us know how it goes!Alex Cheers, --PhilAfter looking over the Xorg log files, I discovered differences in the mappings between the firegl and the radeon drivers. I noticed the maps from both the FireGL driver and radeon driver were very similar. However, there were two differences. First, the fglrx driver has an extra entry: [2] -1 0 0xffe0 - 0x (0x20) MX[B](B)Second, the radeon drivers looks like they have broken mappings. The MMIO range begins at: 0xb010. The last two mappings in the fglrx driver are within that range. However, in the radeon driver, the are offset from 0, yet claim to be in I/O space. (II) resource ranges after probing:DRI broken: [33] 0 0 0x03b0 - 0x03bb (0xc) IS[B] [34] 0 0 0x03c0 - 0x03df (0x20) IS[B]...fglrx: [34] 0 0 0xb01203b0 - 0xb01203bb (0xc) IS[B] [35] 0 0 0xb01203c0 - 0xb01203df (0x20) IS[B]1) What are these mappings used for? 2) Could this incorrect mapping explain the problems that I'm seeing? 3) What part of radeon probe would be responsible for adding these? Thanks,--PhilComplete map (Working FGRLX):(II) resource ranges after preInit: [0] 0 0 0xb010 - 0xb010 (0x1) MX[B] [1] 0 0 0xc000 - 0xcfff (0x1000) MX[B] [2] -1 0 0xffe0 - 0x (0x20) MX[B](B) [3] -1 0 0x0010 - 0x3fff (0x3ff0) MX[B]E(B) [4] -1 0 0x000f - 0x000f (0x1) MX[B] [5] -1 0 0x000c - 0x000e (0x3) MX[B] [6] -1 0 0x - 0x0009 (0xa) MX[B] [7] -1 0 0xb020a400 - 0xb020a4ff (0x100) MX[B] [8] -1 0 0xb0209800 - 0xb02098ff (0x100) MX[B] [9] -1 0 0xb0209c00 - 0xb0209cff (0x100) MX[B] [10] -1 0 0xb020a000 - 0xb020a0ff (0x100) MX[B] [11] -1 0 0xb0206000 - 0xb0207fff (0x2000) MX[B] [12] -1 0 0xb020 - 0xb0203fff (0x4000) MX[B] [13] -1 0 0xb0209000 - 0xb02097ff (0x800) MX[B] [14] -1 0 0xb0204000 - 0xb0205fff (0x2000) MX[B] [15] -1 0 0xb0003800 - 0xb00038ff (0x100) MX[B] [16] -1 0 0xb0003400 - 0xb00034ff (0x100) MX[B] [17] -1 0 0xb0003000 - 0xb00033ff (0x400) MX[B] [18] -1 0 0xb0002000 - 0xb0002fff (0x1000) MX[B] [19] -1 0 0xb0001000 - 0xb0001fff (0x1000) MX[B] [20] -1 0 0xb000 - 0xbfff (0x1000) MX[B] [21] -1 0 0xb010 - 0xb010 (0x1) MX[B](B) [22] -1 0 0xc000 - 0xcfff (0x1000) MX[B](B) [23] 0 0 0x000a - 0x000a (0x1) MS[B] [24] 0 0 0x000b - 0x000b7fff (0x8000) MS[B] [25] 0 0 0x000b8000 - 0x000b (0x8000) MS[B] [26] 0 0 0x9000 - 0x90ff (0x100) IX[B] [27] -1 0 0x - 0x (0x1) IX[B] [28] -1 0 0x - 0x00ff (0x100) IX[B] [29] -1 0 0xa000 - 0xa0ff (0x100) IX[B] [30] -1 0 0x8410 - 0x841f (0x10) IX[B] [31] -1 0 0x8420 - 0x8420 (0x1) IX[B] [32] -1 0 0x8428 - 0x8428 (0x1) IX[B] [33] -1 0 0x8424 - 0x8424 (0x1) IX[B] [34] -1 0 0x8430 - 0x8430 (0x1) IX[B] [35] -1 0 0x8400 - 0x840f (0x10) IX[B] [36] -1 0 0x9000 - 0x90ff (0x100) IX[B](B) [37] 0 0 0xb01203b0 - 0xb01203bb (0xc) IS[B] [38] 0 0 0xb01203c0 - 0xb01203df (0x20) IS[B]Complete map (Broken DRI):(II) resource ranges after preInit: [0] 0 0 0xb010 - 0xb010 (0x1) MX[B] [1] 0 0 0xc000 - 0xcfff (0x1000) MX[B] [2] -1 0 0x0010 - 0x3fff (0x3ff0) MX[B]E(B) [3] -1 0 0x000f - 0x000f (0x1) MX[B] [4] -1 0 0x000c - 0x000e (0x3) MX[B] [5] -1 0 0x - 0x0009 (0xa) MX[B] [6] -1 0 0xb020a400 - 0xb020a4ff (0x100) MX[B] [7] -1 0 0xb0209800 - 0xb02098ff (0x100) MX[B] [8] -1 0 0xb0209c00 - 0xb0209cff (0x100) MX[B] [9] -1 0 0xb020a000 - 0xb020a0ff (0x100) MX[B] [10] -1 0 0xb0206000 - 0xb0207fff (0x2000) MX[B] [11] -1 0 0xb020 - 0xb0203fff (0x4000) MX[B] [12] -1 0 0xb0209000 - 0xb02097ff (0x800) MX[B] [13] -1 0 0xb0204000 - 0xb0205fff (0x2000) MX[B] [14] -1 0 0xb0003800 - 0xb00038ff (0x100) MX[B] [15] -1 0 0xb0003400 - 0xb00034ff (0x100) MX[B] [16] -1 0 0xb0003000 - 0xb00033ff (0x400) MX[B] [17] -1 0 0xb0002000 - 0xb0002fff (0x1000) MX[B] [18] -1 0 0xb0001000 - 0xb0001fff (0x1000) MX[B] [19] -1 0 0xb000 - 0xbfff (0x1000) MX[B] [20] -1 0 0xb010 - 0xb010 (0x1) MX[B](B) [21] -1 0 0xc000 - 0xcfff (0x1000) MX[B](B) [22] 0 0 0x000a - 0x000a (0x1) MS[B](OprU) [23] 0 0
Re: ATI Radeon XPRESS 200M
Alex, Thanks for answering my questions. Sorry I'm a little slow to respond. I can usually only work on this when everyone in the house is asleep. (That doesn't come that often..)
You'd probably want to configure the MC in the DDX (xf86-video-ati)although you may have to coordinate with the drm if things like the
memory maps change.You shouldn't need to mess with the 3D driver(mesa).The DDX sets up the card, sets modes and handles 2D accel andoverlays.The drm provides secure access to the card in the kernelfor things like DMA and command submission.The 3D mesa driver
translates OpenGL to card specific commands and then feeds thecommands to the drm.I greped through a copy of xf86-video-ati that I checked out of git. It seems that R300_MC_IND_INDEX is only manipulated in RADEONInitDispBandwidth. Are there some other places I am missing?
(Or is there something else I should be looking for?)I shouldn't be too hard to add support for the indirect MC regs to
radeontool or another dumper.The indirect MC regs are accessed viathe MC index reg at MMIO offset 0x01F8 and the MC data reg at MMIOoffset 0x01FC.You specify the MC reg you want in the MC index regand then you can read/write to that reg via the MC data reg.bits 5:0
of the MC index reg specify the MC reg.bit 8 is the write enablebit.You should be able to use the INPLL/OUTPLL code in the radeonDDX as a model.the only difference is the PLL write enable bit is 7rather than 8.The PCIE regs are indexed as well IIRC, but once
again, I'm not too familiar with them.Alright, so I took the radeontool and tried to make this happen. First the interesting things: fglrx (8.24.8)--
RADEON_MC_AGP_LOCATION=5bff5800RADEON_MC_FB_LOCATION=57ff4800RADEON_MC_STATUS=00080001R300_MC_INIT_MISC_LAT_TIMER=f0001100xorg-x11-drv-ati-6.5.8.0-1---RADEON_MC_AGP_LOCATION=ffc0
RADEON_MC_FB_LOCATION=57ff4800RADEON_MC_STATUS=00090005R300_MC_INIT_MISC_LAT_TIMER=f000Where are the defines that I can use to interpret these results? .. When I tried to read the MC regs as you specified above, I run into
some problems. Two Problems: 1) If write the index, and then read it back, it is as if somebody zeroed bits 3:1 of the value that I wrote. 2) All of the reads to R300_MC_IND_DATA return 0.
Questions: 1) Am I doing anything obviously wrong? (Code below) 2) Is a value of 0 reasonable for these registers? NOTE: I have another laptop w/ATI that IS supported by the DRIdrivers. I'm gonna try to run the dumper on that an see if the
results are different. (This should help me figure out if my radentool code is bad, or the XPRESS really does set everything to zero..)Here's my code (Based on PLLIN /OUT as you suggested): #define R300_MC_IND_INDEX 0x01f8
# define R300_MC_IND_ADDR_MASK 0x3f#define R300_MC_IND_DATA 0x01fc#define OUTREG8(offset, val) *(volatile unsigned char *)(((unsigned char*)(radeon_cntl_mem)) + (offset)) = (val)
#define INREG(offset) *(volatile unsigned long *)(void *)(((unsigned char*)(radeon_cntl_mem)) + (offset))unsigned int RADEONINMC(int addr){ unsigned int data; OUTREG8(R300_MC_IND_INDEX, (addr R300_MC_IND_ADDR_MASK));
data = ""> printf(Index(Read from R300_MC_IND_INDEX): %lx , INREG(R300_MC_IND_INDEX)); return data;}void radeon_memory_controller(void){ unsigned int i;
for (i=0;i=0x3f;i++) { printf(Index(written to R300_MC_IND_INDEX): %x , i); printf(R300_MC_IND_DATA: %x\n, RADEONINMC(i)); }}Output:
Index(written to R300_MC_IND_INDEX): 0 Index(Read from R300_MC_IND_INDEX): 0 R300_MC_IND_DATA: 0Index(written to R300_MC_IND_INDEX): 1 Index(Read from R300_MC_IND_INDEX): 1 R300_MC_IND_DATA: 0Index(written to R300_MC_IND_INDEX): 2 Index(Read from R300_MC_IND_INDEX): 0 R300_MC_IND_DATA: 0
Index(written to R300_MC_IND_INDEX): 3 Index(Read from R300_MC_IND_INDEX): 1 R300_MC_IND_DATA: 0Index(written to R300_MC_IND_INDEX): 4 Index(Read from R300_MC_IND_INDEX): 0 R300_MC_IND_DATA: 0Index(written to R300_MC_IND_INDEX): 5 Index(Read from R300_MC_IND_INDEX): 1 R300_MC_IND_DATA: 0
Index(written to R300_MC_IND_INDEX): 6 Index(Read from R300_MC_IND_INDEX): 0 R300_MC_IND_DATA: 0Index(written to R300_MC_IND_INDEX): 7 Index(Read from R300_MC_IND_INDEX): 1 R300_MC_IND_DATA: 0Index(written to R300_MC_IND_INDEX): 8 Index(Read from R300_MC_IND_INDEX): 8 R300_MC_IND_DATA: 0
Index(written to R300_MC_IND_INDEX): 9 Index(Read from R300_MC_IND_INDEX): 9 R300_MC_IND_DATA: 0Index(written to R300_MC_IND_INDEX): a Index(Read from R300_MC_IND_INDEX): 8 R300_MC_IND_DATA: 0Index(written to R300_MC_IND_INDEX): b Index(Read from R300_MC_IND_INDEX): 9 R300_MC_IND_DATA: 0
Index(written to R300_MC_IND_INDEX): c Index(Read from R300_MC_IND_INDEX): 8 R300_MC_IND_DATA: 0Index(written to R300_MC_IND_INDEX): d Index(Read from R300_MC_IND_INDEX): 9 R300_MC_IND_DATA: 0Index(written to R300_MC_IND_INDEX): e Index(Read from R300_MC_IND_INDEX): 8 R300_MC_IND_DATA: 0
Is there an overview of how radeons are laid out?I've looks through some
of the DRI documentation (
ATI Radeon XPRESS 200M
Hi All, I know that this topic has come up many times in the past, but here goes. I'm one of the poor schleps with a XPRESS 200M in my Compaq laptop. The open-source driver doesn't support it, and the latest fglrx driver just hangs upon X startup. So... I want to try to fix this. From the DRI mail threads/bug reports that I've read so far, it appears as if the memory controller is radically different than the other ATI cards. There was a post in early September ( http://marc.theaimsgroup.com/?l=dri-develm=115713477422878w=2 ), describing how to support this with the opensource driver. 1) Get an ATI proprietary driver running on the machine. (DONE: fglrx: 8.24.8 FC5)2) Dump MC registers/record initialization sequence (Working on it.)3) Build a custom Xorg webserver with intialization matching the ATI proprietary driver (and will allow DRM to be installed) 4) Fixs bugs goto 3 5) Profit.Questions1) (I'm a complete Xorg/DRI/Mesa developer newbie.) What specific parts of the system have to be changed? Is this a DRM driver issue? Is it something in Mesa? Is it something in the X.org server? (Even better, which files should I look at? ) (radeon_display.c from xf86-video-ati/src looks promising.) 2) What tools are best to dump the radeon register information? I've used radeon_dump to get things after I started up, but it only gives me the final state of the registers. I stumbled upon another dumper here: http://people.freedesktop.org/~glisse/. (I think that this will track register initialization through-out the startup process). Are these the best tools to use? 3) Finally, where is the best place to discuss the ATI development/ask questions? Is there an overview of how radeons are laid out? I've looks through some of the DRI documentation ( http://dri.freedesktop.org/wiki/Documentation), but none seem to reference the radeon specifically. NOTE: I don't know if this is typical of most graphics cards, but the hyper-memory on the XPress cards seems to be more than just a software manager. According to ( http://www.ati.com/technology/HyperMemory_Whitepaper.pdf), there is also a PCI express auxilary channel that can shuffle things back and forth from the VPU to memory. Cheers Thanks,--Phil - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Radeon 8800 drivers
Hi All, This question has to do with the Radeon 8800 drivers that ATI just released. I know that they were written by ATI, but I have a question that I believe is an DRI questions. 1) We have 15 identical machines each with a Radeon 8500. Intermittently, DRI will fail with the following error in /var/log/XFree86.0.log: (EE) fglr200(0): [DRM] Failed to allocate texture sarea! (EE) fglr200(0): [drm] failed to remove DRM signal handler dmesg shows the following: Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 816M agpgart: Unsupported Intel chipset (device id: 2531), you might want to try agp_try_unsupported=1. agpgart: no supported devices found. [fglr200] Maximum main memory to use for locked dma buffers: 921 MBytes. [fglr200] module loaded - fglr200 1.2.0 [May 28 2002] on minor 0 Fire GL built-in AGP-support Based on agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 816M agpgart: Detected Intel i860 chipset agpgart: AGP aperture is 64M @ 0xe800 [fglr200] AGP detected, AgpState = 0x1f000217 (hardware caps) [fglr200] AGP enabled, AgpCommand = 0x1f000314 (selected caps) [fglr200:firegl_addmap] *ERROR* vmalloc failed! [fglr200:drm_ioremapfree] *ERROR* [mappings] Attempt to free NULL pointer [fglr200:drm_ioremapfree] *ERROR* [mappings] Excess frees: 5 frees, 4 allocs [fglr200:firegl_addmap] *ERROR* vmalloc failed! [fglr200:drm_ioremapfree] *ERROR* [mappings] Attempt to free NULL pointer [fglr200:drm_ioremapfree] *ERROR* [mappings] Excess frees: 8 frees, 7 allocs [fglr200:drm_ioremapfree] *ERROR* [mappings] Excess frees: 9 frees, 7 allocs [fglr200:firegl_addmap] *ERROR* vmalloc failed! [fglr200:drm_ioremapfree] *ERROR* [mappings] Attempt to free NULL pointer [fglr200:drm_ioremapfree] *ERROR* [mappings] Excess frees: 11 frees, 10 allocs [fglr200:drm_ioremapfree] *ERROR* [mappings] Excess frees: 12 frees, 10 allocs [fglr200:drm_ioremapfree] *ERROR* [mappings] Excess frees: 13 frees, 10 allocs [fglr200:firegl_addmap] *ERROR* vmalloc failed! [fglr200:drm_ioremapfree] *ERROR* [mappings] Attempt to free NULL pointer [fglr200:drm_ioremapfree] *ERROR* [mappings] Excess frees: 14 frees, 13 allocs [fglr200:drm_ioremapfree] *ERROR* [mappings] Excess frees: 15 frees, 13 allocs [fglr200:drm_ioremapfree] *ERROR* [mappings] Excess frees: 16 frees, 13 allocs [fglr200:drm_ioremapfree] *ERROR* [mappings] Excess frees: 17 frees, 13 allocs [fglr200:firegl_addmap] *ERROR* vmalloc failed! [fglr200:drm_ioremapfree] *ERROR* [mappings] Attempt to free NULL pointer [fglr200:drm_ioremapfree] *ERROR* [mappings] Excess frees: 18 frees, 16 allocs [fglr200:drm_ioremapfree] *ERROR* [mappings] Excess frees: 19 frees, 16 allocs [fglr200:drm_ioremapfree] *ERROR* [mappings] Excess frees: 20 frees, 16 allocs [fglr200:drm_ioremapfree] *ERROR* [mappings] Excess frees: 21 frees, 16 allocs Working Version: Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 816M agpgart: Unsupported Intel chipset (device id: 2531), you might want to try agp_try_unsupported=1. agpgart: no supported devices found. [fglr200] Maximum main memory to use for locked dma buffers: 921 MBytes. [fglr200] module loaded - fglr200 1.2.0 [May 28 2002] on minor 0 Fire GL built-in AGP-support Based on agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 816M agpgart: Detected Intel i860 chipset agpgart: AGP aperture is 64M @ 0xe800 [fglr200] AGP detected, AgpState = 0x1f000217 (hardware caps) [fglr200] AGP enabled, AgpCommand = 0x1f000314 (selected caps) [fglr200:firegl_addmap] *ERROR* vmalloc failed! [fglr200:drm_ioremapfree] *ERROR* [mappings] Attempt to free NULL pointer [fglr200:drm_ioremapfree] *ERROR* [mappings] Excess frees: 5 frees, 4 allocs [fglr200:drm_ioremapfree] *ERROR* [mappings] Attempt to free NULL pointer [fglr200:drm_ioremapfree] *ERROR* [mappings] Excess frees: 8 frees, 7 allocs [fglr200:drm_ioremapfree] *ERROR* [mappings] Excess frees: 9 frees, 7 allocs ... The systems have plenty of memory free: total used free sharedbuffers cached Mem: 1027860 213040 814820 72 57076 70460 -/+ buffers/cache: 85504 942356 Swap: 900088 0 900088 So Does anyone know why would vmalloc fail? --Phil Hewlett-Packard: High Performance Technical Computing/Visualization --- [EMAIL PROTECTED]Performance/Development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Dri-devel mailing list [EMAIL PROTECTED]
