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. > 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 _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
