Hi,
I am wondering what is the format of CPU-DRAM DQ byte map for FSP-M configuration. Typically there are 64 DQ lanes per non-ECC SODIMM/DIMM (correct me if I'm wrong) for DDR4 for example. But the DQ map is an 2x12 array, so I assume 12 bytes for each channel (why not 8 bytes?). My questions are:
1. Why there are more bytes in array than DQ lanes? 2. How should I define the DQ map? Does 0xFF or 0x00 mean 1 to 1 mapping? 3. Some FSP2.0 mainboards have values like 0x0F and 0xF0 in their mappings which looks like 1 byte swap, but there are also 0xCC and 0x33. What is the difference?
The DQS mapping is clear to me (rather obvious as there are only 8 DQS which matches the 2x8 array).
I know about 3 Rcomp resistors of the chipset and what they are for, but what RcompTarget is? In the code I can see function `mainboard_fill_rcomp_strength_data` and begin to wonder what rcomp strength is (not Rcomp Target?). How to correctly fill RcompTarget FSP-M configuration?
Any tips and pointers appreciated.
Regards,
Hi Michal,
On 29.03.19 16:49, Michal Zygowski wrote:
I am wondering what is the format of CPU-DRAM DQ byte map for FSP-M configuration. Typically there are 64 DQ lanes per non-ECC SODIMM/DIMM (correct me if I'm wrong) for DDR4 for example. But the DQ map is an 2x12 array, so I assume 12 bytes for each channel (why not 8 bytes?). My questions are:
- Why there are more bytes in array than DQ lanes?
it's actually not an array but a rather complex structure. You can find some clues in the Skylake FSP Integration Guide [1] and also in coreboot header files [2]. I have no idea why the documentation was removed from future guides.
- How should I define the DQ map? Does 0xFF or 0x00 mean 1 to 1 mapping?
If you have DDR4 (SO)DIMMs, you probably shouldn't. [2] mentions that it's for memory-down configurations with LPDDR3 only. And, AFAIR, an investigation into the deep of the KBL FSP source didn't find any relation to DDR4.
I know about 3 Rcomp resistors of the chipset and what they are for, but what RcompTarget is? In the code I can see function `mainboard_fill_rcomp_strength_data` and begin to wonder what rcomp strength is (not Rcomp Target?). How to correctly fill RcompTarget FSP-M configuration?
Please tell me if you find out ;) even Intel developers working on coreboot don't know. Some insider came back quoting identifiers from comments in the FSP header... identifiers nowhere to be found in source/documentation.
My guess is that the targets are either computed or even measured by some very confidential tool.
Nico
[1] https://github.com/IntelFsp/FSP/raw/master/SkylakeFspBinPkg/Docs/SkylakeFspI... [2] https://review.coreboot.org/cgit/coreboot.git/tree/src/soc/intel/broadwell/i...
DDR RComp calculation is explained in the CPU platform design guide. If you are an Intel licensee, you can request this document by number - 561280 for KBL. There seems to be also a whitepaper you can ask your OEM rep for. The actual values are calculated based on memory topology and board layout and then fine-tuned through measurement. Basically, if you are a system designer, you have the documents and know how to do it, and if you are not, then these values are calculated by the manufacturer/BIOS writer so your only recourse is to find out from them.
Similarly, DQ array is filled according to the information supplied by the system designer. Intel CPUs allow certain freedom in routing the memory pins to simplify the board layout task. The pin map should be filled for DQ/DQS according to the physical connectivity chosen by the system designer.
Bottom line - it's not something you can figure out by looking at a motherboard
________________________________________ From: Nico Huber nico.h@gmx.de Sent: Friday, March 29, 2019 10:03 AM To: Michal Zygowski; coreboot@coreboot.org Subject: [coreboot] Re: FSP2.0 DQ byte map
Hi Michal,
On 29.03.19 16:49, Michal Zygowski wrote:
I am wondering what is the format of CPU-DRAM DQ byte map for FSP-M configuration. Typically there are 64 DQ lanes per non-ECC SODIMM/DIMM (correct me if I'm wrong) for DDR4 for example. But the DQ map is an 2x12 array, so I assume 12 bytes for each channel (why not 8 bytes?). My questions are:
- Why there are more bytes in array than DQ lanes?
it's actually not an array but a rather complex structure. You can find some clues in the Skylake FSP Integration Guide [1] and also in coreboot header files [2]. I have no idea why the documentation was removed from future guides.
- How should I define the DQ map? Does 0xFF or 0x00 mean 1 to 1 mapping?
If you have DDR4 (SO)DIMMs, you probably shouldn't. [2] mentions that it's for memory-down configurations with LPDDR3 only. And, AFAIR, an investigation into the deep of the KBL FSP source didn't find any relation to DDR4.
I know about 3 Rcomp resistors of the chipset and what they are for, but what RcompTarget is? In the code I can see function `mainboard_fill_rcomp_strength_data` and begin to wonder what rcomp strength is (not Rcomp Target?). How to correctly fill RcompTarget FSP-M configuration?
Please tell me if you find out ;) even Intel developers working on coreboot don't know. Some insider came back quoting identifiers from comments in the FSP header... identifiers nowhere to be found in source/documentation.
My guess is that the targets are either computed or even measured by some very confidential tool.
Nico
[1] https://github.com/IntelFsp/FSP/raw/master/SkylakeFspBinPkg/Docs/SkylakeFspI... [2] https://review.coreboot.org/cgit/coreboot.git/tree/src/soc/intel/broadwell/i... _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On 29.03.2019 18:03, Nico Huber wrote:
Hi Michal,
Hi Nico,
On 29.03.19 16:49, Michal Zygowski wrote:
I am wondering what is the format of CPU-DRAM DQ byte map for FSP-M configuration. Typically there are 64 DQ lanes per non-ECC SODIMM/DIMM (correct me if I'm wrong) for DDR4 for example. But the DQ map is an 2x12 array, so I assume 12 bytes for each channel (why not 8 bytes?). My questions are:
- Why there are more bytes in array than DQ lanes?
it's actually not an array but a rather complex structure. You can find some clues in the Skylake FSP Integration Guide [1] and also in coreboot header files [2]. I have no idea why the documentation was removed from future guides.
I have read the KabyLake FSP Integration guide, but there is only an information about the values' existence in FSP UPD. Definitely will look at those files too.
- How should I define the DQ map? Does 0xFF or 0x00 mean 1 to 1 mapping?
If you have DDR4 (SO)DIMMs, you probably shouldn't. [2] mentions that it's for memory-down configurations with LPDDR3 only. And, AFAIR, an investigation into the deep of the KBL FSP source didn't find any relation to DDR4.
Good to know I will not have to bother with it.
I know about 3 Rcomp resistors of the chipset and what they are for, but what RcompTarget is? In the code I can see function `mainboard_fill_rcomp_strength_data` and begin to wonder what rcomp strength is (not Rcomp Target?). How to correctly fill RcompTarget FSP-M configuration?
Please tell me if you find out ;) even Intel developers working on coreboot don't know. Some insider came back quoting identifiers from comments in the FSP header... identifiers nowhere to be found in source/documentation.
I have some clues about it actually. I have found some information after diving into network abyss. There is a motherboard manual[3] which gives a tiny bit of explanation of those RcompTarget values. Here is the fragment from BIOS settings, Memory Overclocking section, page 89:
RcompTarget[RdOdt] Enter a value for desired Rcomptarget[RdOdt]. The default is 60.
RcompTarget[WrDS] Enter a value for desired RcompTarget[WrDS]. The default is 26.
RcompTarget[WrDSCmd] Enter a value for desired RcompTarget[WrDSCmd]. The default is 20.
RcompTarget[WrDSCtl] Enter a value for desired RcompTarget[WrDSCtl]. The default is 20.
RcompTarget[WrDSClk] Enter a value for desired RcompTarget[WrDSClk]. The default is 26.
Interestingly also 5 byte values as defined in FSP UPD. The strings in square brackets seem to be some DDR standard terms. Maybe someone on the mailing list would know something about it.
My guess is that the targets are either computed or even measured by some very confidential tool.
Nico
[1] https://github.com/IntelFsp/FSP/raw/master/SkylakeFspBinPkg/Docs/SkylakeFspI... [2] https://review.coreboot.org/cgit/coreboot.git/tree/src/soc/intel/broadwell/i... _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Thank You Nico. Best regards,
[3] https://www.supermicro.com/manuals/motherboard/X299/MNL-2001.pdf
Hi Alex,
On 30.03.2019 02:40, Alex Feinman wrote:
DDR RComp calculation is explained in the CPU platform design guide. If you are an Intel licensee, you can request this document by number - 561280 for KBL. There seems to be also a whitepaper you can ask your OEM rep for. The actual values are calculated based on memory topology and board layout and then fine-tuned through measurement. Basically, if you are a system designer, you have the documents and know how to do it, and if you are not, then these values are calculated by the manufacturer/BIOS writer so your only recourse is to find out from them.
I have the means to access that document. Thank You for pointing it out, it will be very helpful. The calculation are probably very complex, but not something I cannot figure out (hopefully). I would rather solve it by myself and as a last resort contact board manufacturer when stuck in memory initialization problems. And if possible and not restricted by NDAs, contribute the knowledge to raise the experience of whole community.
Similarly, DQ array is filled according to the information supplied by the system designer. Intel CPUs allow certain freedom in routing the memory pins to simplify the board layout task. The pin map should be filled for DQ/DQS according to the physical connectivity chosen by the system designer.
Bottom line - it's not something you can figure out by looking at a motherboard
Of course I am aware of that. I have the board schematics, so I know which pins are swizzled and the reason behind that obviously. Just the format of bytes for FSP UPD was not clear to me. Nico has pointed some places where to look for information in coreboot tree. However, I will definitely look at platform design guide You have mentioned.
Thank You for help Alex. Best regards, Michał
From: Nico Huber nico.h@gmx.de Sent: Friday, March 29, 2019 10:03 AM To: Michal Zygowski; coreboot@coreboot.org Subject: [coreboot] Re: FSP2.0 DQ byte map
Hi Michal,
On 29.03.19 16:49, Michal Zygowski wrote:
I am wondering what is the format of CPU-DRAM DQ byte map for FSP-M configuration. Typically there are 64 DQ lanes per non-ECC SODIMM/DIMM (correct me if I'm wrong) for DDR4 for example. But the DQ map is an 2x12 array, so I assume 12 bytes for each channel (why not 8 bytes?). My questions are:
- Why there are more bytes in array than DQ lanes?
it's actually not an array but a rather complex structure. You can find some clues in the Skylake FSP Integration Guide [1] and also in coreboot header files [2]. I have no idea why the documentation was removed from future guides.
- How should I define the DQ map? Does 0xFF or 0x00 mean 1 to 1 mapping?
If you have DDR4 (SO)DIMMs, you probably shouldn't. [2] mentions that it's for memory-down configurations with LPDDR3 only. And, AFAIR, an investigation into the deep of the KBL FSP source didn't find any relation to DDR4.
I know about 3 Rcomp resistors of the chipset and what they are for, but what RcompTarget is? In the code I can see function `mainboard_fill_rcomp_strength_data` and begin to wonder what rcomp strength is (not Rcomp Target?). How to correctly fill RcompTarget FSP-M configuration?
Please tell me if you find out ;) even Intel developers working on coreboot don't know. Some insider came back quoting identifiers from comments in the FSP header... identifiers nowhere to be found in source/documentation.
My guess is that the targets are either computed or even measured by some very confidential tool.
Nico
[1] https://github.com/IntelFsp/FSP/raw/master/SkylakeFspBinPkg/Docs/SkylakeFspI... [2] https://review.coreboot.org/cgit/coreboot.git/tree/src/soc/intel/broadwell/i... _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi Alex, all,
Am 30.03.19 um 02:40 schrieb Alex Feinman:
DDR RComp calculation is explained in the CPU platform design guide. If you are an Intel licensee, you can request this document by number - 561280 for KBL. There seems to be also a whitepaper you can ask your OEM rep for.
that mention of a whitepaper made me search intel.com again. And... finally! I found something. For all with cNDA access: 573387 It's a few slides that explain at least when we have to fill which fields, and a spreadsheet that gives all the numbers (even convenient "computation" of the DQ map stuff for LPDDR). I have no idea why they didn't make that part of FSP, the interface could be so much simpler.
The actual values are calculated based on memory topology and board layout and then fine-tuned through measurement. Basically, if you are a system designer, you have the documents and know how to do it, and if you are not, then these values are calculated by the manufacturer/BIOS writer so your only recourse is to find out from them.
I highly doubt that now. All numbers in coreboot match those in Intel's spreadsheet. So they don't seem to be board specific but only SKU and memory configuration specific (e.g. memory-down vs DIMMs). Even if Intel leaves room for tuning, nobody seems to make use of it.
Well, at least Intel seems to have realized by now that this makes FSP configuration unnecessarily complex: The CNL FSP seems to come with default values (for the Rcomp settings).
I guess, I'll try to get the data from that spreadsheet published. With those tables we can derive all the settings from other information and wouldn't have to set them per board.
Nico
PS. Haha, I've searched for years for this info :D
-
Alex Feinman -
Michal Zygowski -
Nico Huber -
Nico Huber