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
0x57fe0000-0x58000000)
> The CP is mapped at 0x58000000. (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
0xc8000000 to 0xcffffffff.
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-0xCFFE0000.
So, there was something already at 0xCFFE0000 - 0xCFFFFFFF, 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 0x20000 bytes
hex.
Which would exactly fit between 0xCFFE0000 - 0xCFFFFFFF. 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 0x34b40000 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
> 0x04000000 [67108864]
> RADEON_CONFIG_APERSIZE: 0x4000000
>
> 0x00000130 -> 0x40800000
> decoding as RADEON_HOST_PATH_CNTL
> 0x40800000 [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.php&p=sourceforge&CID=DEVDEV
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
