Paul Durrant wrote: > Christian Kaiser wrote: > >> OK... I dont't understand this at all. I did a 32-bit read on all >> BARs. Maybe you can explain me this? >> >> 0x10 0xc8300000 >> 0x12 0xbeefc830 >> 0x14 0x0 >> 0x16 0x0 >> 0x18 0xd8000000 >> 0x20 0xd0000000 >> 0x22 0xbeefd000 >> 0x24 0xcc000000 >> 0x26 0xcc00 >> > > Those are 32-bit reads at 16-bit intervals; I'd hazard a guess and say > that the 0xbeef you see here is part of 0xdeadbeef because you're > displaying uninitialized memory. Please do 32-bit reads at 32-bit > intervals. >
Yes... I totally screwed that up! >> However, this is what I get from prtconf -vp >> >> Node 0x000020 >> assigned-addresses: >> 82050010.00000000.c8300000.00000000.00040000.82050018.00000000.d8000000.00000000.04000000.8205001c.00000000.d4000000.00000000.04000000.82050020.00000000.d0000000.00000000.04000000.82050024.00000000.cc000000.00000000.04000000 >> >> >> reg: >> 00050000.00000000.00000000.00000000.00000000.02050010.00000000.00000000.00000000.00040000.02050018.00000000.00000000.00000000.04000000.0205001c.00000000.00000000.00000000.04000000.02050020.00000000.00000000.00000000.04000000.02050024.00000000.00000000.00000000.04000000 >> >> > > These are arrays of 5-tuples describing your BARs and what has been > programmed into them (although the 'reg' prop has an extra one for your > config. space). So, if we break assigned-addresses up: > > A: 82050010.00000000.c8300000.00000000.00040000 > B: 82050018.00000000.d8000000.00000000.04000000 > C: 8205001c.00000000.d4000000.00000000.04000000 > D: 82050020.00000000.d0000000.00000000.04000000 > E: 82050024.00000000.cc000000.00000000.04000000 > > Now, if you look at usr/src/uts/common/sys/pci.h you'll see an > explanation of how to decode these. > Let's take A and put the first 32-bits in binary: > > npXX XXtt bbbb bbbb dddd dfff rrrr rrrr > 1000 0010 0000 0101 0000 0000 0001 0000 > > So: > > n = 1 non-relocatable > p = 0 non-prefetchable > tt = 2 memory space > bbbbbbbb = 5 bus 5 > ddddd = 0 device 0 > fff = 0 function 0 > rrrrrrrr = 0x10 register 16 > > I don't quite know why the register numbers start at 16, but then we > have a jump of 8 to the next one (i.e. bottom byte of B's first 32-bits > is 0x18) then we have jumps of 4 after that. This is consistent with the > 'hole' in your BARs. > The last 32-bits of each 5 tuple show the size of each of the BARs so we > can see that: > > A is 256k > B thru E are 64M > > Does this make sense? > > Paul > Thanks Paul! That helped a lot! But there is still one minor thing confusing me. Why is ddi_dev_nregs() returning nregs=6 and not nregs=5? Christian -- Christian Kaiser, Software Engineer, Dolphin Interconnect Solutions http//www.dolphinics.com _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
