if anybody wants to dash this off today, we need it.
The utillity would read the routing registers in k8 north and print out what they mean. You get this info from config space.
I wrote one of these for the ultra 40 project and then lost it when I shipped the machine back to xtreme data ...
it's easy but I don't have time today. It might tell us what is up with v3/serengeti.
ron
On Fri, Oct 10, 2008 at 5:18 PM, ron minnich rminnich@gmail.com wrote:
Could you explain what you call "routing registers"
I might give that a shot if it's not too difficult
On Fri, Oct 10, 2008 at 11:37 AM, Vincent Legoll vincent.legoll@gmail.com wrote:
get this doc:
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/3255...
see page: 72 address map
it's very well written and also very easy to figure out.
You can start using setpci to get each register value out, then write simple functions for each register type to decode it. Take the simple function approach so we can use these in coreinfo, libpayload, coreboot, or whereever.
ron
Is that like what you had in mind:
~ # ./AMDK8MemMap.py 0x00: Ox1022 - Device ID 0x02: Ox1101 - Vendor ID 0x04: Ox0000 - Status 0x06: Ox0000 - Command 0x08: Ox00 - Base CLass Code 0x09: Ox00 - Subclass Code 0x0a: Ox00 - Program Interface 0x0b: Ox06 - Revision ID 0x0c: Ox00 - Built In Self Test 0x0d: Ox00 - Header Type 0x0e: Ox80 - Latency Timer 0x0f: Ox00 - Cache Line Size 0x10: Ox00000000 - Base Address 0 0x14: Ox00000000 - Base Address 1 0x18: Ox00000000 - Base Address 2 0x1c: Ox00000000 - Base Address 3 0x20: Ox00000000 - Base Address 4 0x24: Ox00000000 - Base Address 5 0x28: Ox00000000 - Card Bus CIS Pointer 0x2c: Ox0000 - Subsystem ID 0x2e: Ox0000 - Subsystem Vendor ID 0x30: Ox00000000 - ROM Base Address 0x34: Ox00000000 - Capabilities 0x38: Ox00000000 - Reserved 0x3c: Ox00 - Maximum Latency 0x3d: Ox00 - Minimum GNT 0x3e: Ox00 - Interrupt Pin 0x3f: Ox00 - Interrupt Line 0x40: Ox00000003 - DRAM Base 0 0x44: Ox007f0000 - DRAM Limit 0 0x48: Ox00000000 - DRAM Base 1 0x4c: Ox00000001 - DRAM Limit 1 0x50: Ox00000000 - DRAM Base 2 0x54: Ox00000002 - DRAM Limit 2 0x58: Ox00000000 - DRAM Base 3 0x5c: Ox00000003 - DRAM Limit 3 0x60: Ox00000000 - DRAM Base 4 0x64: Ox00000004 - DRAM Limit 4 0x68: Ox00000000 - DRAM Base 5 0x6c: Ox00000005 - DRAM Limit 5 0x70: Ox00000000 - DRAM Base 6 0x74: Ox00000006 - DRAM Limit 6 0x78: Ox00000000 - DRAM Base 7 0x7c: Ox00000007 - DRAM Limit 7 0x80: Ox00e00003 - Memory Mapped I/O Base 0 0x84: Ox00efff80 - Memory Mapped I/O Limit 0 0x88: Ox00feb003 - Memory Mapped I/O Base 1 0x8c: Ox00fec080 - Memory Mapped I/O Limit 1 0x90: Ox00000000 - Memory Mapped I/O Base 2 0x94: Ox00000000 - Memory Mapped I/O Limit 2 0x98: Ox00000000 - Memory Mapped I/O Base 3 0x9c: Ox00000000 - Memory Mapped I/O Limit 3 0xa0: Ox00000000 - Memory Mapped I/O Base 4 0xa4: Ox00000000 - Memory Mapped I/O Limit 4 0xa8: Ox00000000 - Memory Mapped I/O Base 5 0xac: Ox00000000 - Memory Mapped I/O Limit 5 0xb0: Ox00000a03 - Memory Mapped I/O Base 6 0xb4: Ox00000b00 - Memory Mapped I/O Limit 6 0xb8: Ox00800003 - Memory Mapped I/O Base 7 0xbc: Ox00fed300 - Memory Mapped I/O Limit 7 0xc0: Ox00000000 - PCI I/O Base 0 0xc4: Ox00000000 - PCI I/O Limit 0 0xc8: Ox00001013 - PCI I/O Base 1 0xcc: Ox000ff000 - PCI I/O Limit 1 0xd0: Ox00000000 - PCI I/O Base 2 0xd4: Ox00000000 - PCI I/O Limit 2 0xd8: Ox00000000 - PCI I/O Base 3 0xdc: Ox00000000 - PCI I/O Limit 3 0xe0: Oxff000003 - Configuration Base & Limit 0 0xe4: Ox00000000 - Configuration Base & Limit 1 0xe8: Ox00000000 - Configuration Base & Limit 2 0xec: Ox00000000 - Configuration Base & Limit 3 0xf0: Ox00000000 - DRAM Hole Address
On the same machine:
~ # lspci -vvvxxx -s 0:0:18.1 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- 00: 22 10 01 11 00 00 00 00 00 00 00 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 03 00 00 00 00 00 7f 00 00 00 00 00 01 00 00 00 50: 00 00 00 00 02 00 00 00 00 00 00 00 03 00 00 00 60: 00 00 00 00 04 00 00 00 00 00 00 00 05 00 00 00 70: 00 00 00 00 06 00 00 00 00 00 00 00 07 00 00 00 80: 03 00 e0 00 80 ff ef 00 03 b0 fe 00 80 c0 fe 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 03 0a 00 00 00 0b 00 00 03 00 80 00 00 d3 fe 00 c0: 00 00 00 00 00 00 00 00 13 10 00 00 00 f0 0f 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 03 00 00 ff 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
On Fri, Oct 10, 2008 at 5:06 PM, Vincent Legoll vincent.legoll@gmail.com wrote:
Is that like what you had in mind:
This is 18:1 right?
0 to 40 is not really needed.
Would be nice to convert these to actual addresses.
This is a good start but what you are missing is the interpretation of the fields and shifting things so we know what they really are.
That's critical. So you need to do a bit more here -- break out the address range, shift to to show the real address, then break out the node and cpu ids.
This is very close to what we need!
I hope the .py is not doing the config reads itself.
ron minnich wrote:
This is a good start but what you are missing is the interpretation of the fields and shifting things so we know what they really are.
This is exactly what msrtool does. I must apologize for letting it bitrot on my disk just because the two killer features weren't implemented.
I'll try to whip it up tomorrow evening. Maybe it should be regtool instead and do both PCI registers and MSRs.
//Peter
On Sat, Oct 11, 2008 at 7:31 AM, Peter Stuge peter@stuge.se wrote:
the killer features you speak about are those Ron asked ? Or are there other useful things that tool could do ?
I'll try to whip it up tomorrow evening. Maybe it should be regtool instead and do both PCI registers and MSRs.
I would be curious to read your code.
don't forget -- at some point we need C functions I can plug into coreboot directly so that we can have coreboot dump the "state of the world" as it comes up. Very handy when you can't boot linux to run python :-)
ron
On Sat, Oct 11, 2008 at 5:26 PM, ron minnich rminnich@gmail.com wrote:
I'll finish the python prototype before starting to work on a C version, though...
On Sat, Oct 11, 2008 at 8:36 AM, Vincent Legoll vincent.legoll@gmail.com wrote:
That's *always* a good idea :-)
ron
Would that be the kind of decoding you had in mind ?
0x80: Ox00E00003 - Memory Mapped I/O Base 0 DRAM Base: 0x00E0000000 Read Enable: 0x1 Write Enable: 0x1 Interleave Enable: No interleave 0x84: Ox00EFFF80 - Memory Mapped I/O Limit 0 Dst Node ID: 0 Interleave select: 0b111 DRAM Limit: 0x00EFFFFFFF
That is really nice. Yes, now we just need it for config and io and prefmem space :-)
ron
On Sat, Oct 11, 2008 at 10:31 PM, ron minnich rminnich@gmail.com wrote:
You mean 0x80h to 0xECh ? MMIO base / limit PCI IO base / limit Config base / limit
That's my next target...
I have questions, though:
- I've got reserved values for Interleave Enable: Reserved 0b010, is that normal, or a bug in my code ?
- In the doc, page 70 of 26094.pdf
3.4.4 DRAM Address Map [...] For the purposes of this comparison, the lower unspecified bits of the base are assumed to be 0s and the lower unspecified bits of the limit are assumed to be 1s. [...]
For the limit registers I assumed the unspecified bits are 0-24, and I set them to 0xFFFFFF. Is that the right thing to do ? Idem for base registers, with 24 bits set to 0x000000 ?
On Sat, Oct 11, 2008 at 1:51 PM, Vincent Legoll vincent.legoll@gmail.com wrote:
great!
probably normal but not sure. What kind of machine are you testing on?
exactly.
thanks
ron
On Sat, Oct 11, 2008 at 11:45 PM, ron minnich rminnich@gmail.com wrote:
Almost there...
My bad, I decoded mmio registers as dram ones.
and PCI IO address mask is 0x3FFF, right ?
will probably post the script tomorrow...
On Sat, Oct 11, 2008 at 2:53 PM, Vincent Legoll vincent.legoll@gmail.com wrote:
and PCI IO address mask is 0x3FFF, right ?
I think so, unless it is 3fff<<3
Then we just need C code :-)
ron
On Sat, Oct 11, 2008 at 11:56 PM, ron minnich rminnich@gmail.com wrote:
and PCI IO address mask is 0x3FFF, right ?
I think so, unless it is 3fff<<3
Yes, in the register, it is shifted by 3 bytes
Then we just need C code :-)
That is another story...
Here is the python script, I have tested it on my SN25p / opteron 165
I attached the output from a run under legacy BIOS: $ AMDK8MemMap.py -i > output.txt
with a $ lspci -xxx -s 0:0:18.1 > lspci.txt for reference
Could someone double check I did not misinterpreted the doc in the decoding of the registers.
I would be interested in having the output of the tool and the lspci, like above, from something more interesting, like a Tyan 2 or 4 processors motherboard. I'm also interested in --test output.
Try --help to have the list of available options.
I did not use the "Fam 0Fh" 32559.pdf documentation, because I only have an opteron 939 to test on. But after a quick glance, it all looks the same, so it should work as-is.
I'd also like comments, and any ideas for further improvements.
If this is useful, it is: Signed-off-by: Vincent Legoll vincent.legoll@gmail.com and could go somewhere in the utils directory...
Here is the code in C.
This code is simple enough to put into stage 2.
I will look at that next. People can check me on this code.
ron
On Sat, Oct 11, 2008 at 2:52 AM, ron minnich rminnich@gmail.com wrote:
yes
I implemented all I saw in the documentation, I'll add an option to only show memory map regs
Yes, that was just a first step, I saw the sub register interpretation in the doc but it was late and I had to go get some ZZZ, I'll look at that next.
Cool
I hope the .py is not doing the config reads itself.
The .py is calling setpci on each register, that's slow, but who cares ? It only takes a fraction of a second to dump all registers anyways...
I'll do a little bit more work on it before posting, unless someone really need it in it's current state.
-
Peter Stuge -
ron minnich -
Vincent Legoll