Hello Maurice, Thanks for the quick feedback. Your response is clear but I do have one follow up remark. In most cases the difference between various memory configurations is very small (memory only) in these cases using the BomID sounds like the best alternative. My question now is, how do I use this? Can this only be used from the code or can I also use it using the configuration data by creating a DSC or adding it to a DLT. I haven't seen any signs of that and this mechanism only seems to use the PlatformID. My other alternative is to add the available SPD's using a DSC and using the BomID combined with a fixed table to assign the SPD's to a channel. Best Regards, Wim Vervoorn From: Ma, Maurice [mailto:maurice.ma@intel.com] Sent: Tuesday, August 13, 2019 7:40 PM To: Wim Vervoorn <wvervoorn(a)eltan.com&gt;; sbl-devel(a)lists.01.org Subject: RE: Improving onboard memory support Hi, Wim, For the 1st question, there are two different levels. If the boards are very different, we usually use different Board ID and handle them using DLT files to list the difference between this board and the default CFGDATA. If the boards are very close (EX: only memory configuration is different), we can use SetPlatformBomId()/GetPlatformBomId to set BOM ID using platform specific mechanism. Then code can be added in platform package to handle the difference. If you prefer using Board ID to handle the memory configuration difference, it is also OK. I think the duplication in delta files can be mitigated using include file. So these delta file can include a common file and then just list the memory configuration difference for that board. We can add "!include" support in DLT file. For the 2nd issue you mentioned, Yes, it makes perfect sense. The general guidance is to break larger configuration items into smaller TAGS so that it is easier to maintain. Since SPD data is big, we have made the SPD CFG data as separate configuration tag for some of internal projects. We will do it for open sourced CFL/WHL projects soon. Thank you for providing these valuable feedback! Thanks Maurice From: Sbl-devel [mailto:sbl-devel-bounces@lists.01.org] On Behalf Of Wim Vervoorn Sent: Tuesday, August 13, 2019 1:11 To: sbl-devel@lists.01.org<mailto:sbl-devel@lists.01.org> Subject: [Sbl-devel] Improving onboard memory support Hello, When working on a system with onboard memory I am running into a drawback of the way the SPD configuration for onboard memory systems is implemented. Please correct me if I am wrong but as I see it now the way to implement a board that can have multiple memory configurations is to assign multiple board ids and create a dlt file for each ID and integrate the SPD files for that configuration in this dlt. The first thing that I run into is that I need to duplicate all settings and update the memory configuration for this board id. Because of the duplication more maintenance is required. To resolve this it would be required to allow the board id to be split in several items so it can become more modular. For the memory case we would need a couple of bits to figure out what the memory configuration on this board is. Besides this there is another issue. If you have a board that can contains several types of memory and also have banks that are populated and others that are not we are now wasting a lot of configuration space. Each configuration is now using 2K bytes of space just because the system reserves this in the memory parameters. My suggestion would be to separate the SPD space from the remainder of the memory configuration. One area can then contain the SPD data while the MemorySpdPtr00 etc only contain a pointer to the correct SPD (0 if no spd is used, 1 for the 2nd etc). I think this would make the memory configuration for onboard memory systems much more flexible. Best Regards, Wim Vervoorn Eltan B.V. Ambachtstraat 23 5481 SM Schijndel The Netherlands T : +31-(0)73-594 46 64 E : wvervoorn@eltan.com<mailto:wvervoorn@eltan.com> W : http://www.eltan.com<http://www.eltan.com/> "THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR, PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664 OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES."

Hello Maurice, This is clear. I already noticed the addition of the !include support as well. This is great. Best Regards, Wim Vervoorn From: Ma, Maurice [mailto:maurice.ma@intel.com] Sent: Wednesday, August 14, 2019 3:32 PM To: Wim Vervoorn <wvervoorn(a)eltan.com&gt;; sbl-devel(a)lists.01.org Subject: RE: Improving onboard memory support Hi, Wim, Currently BomID is not directly associated with configuration data, and only BoardID is. The BomID handling will need to be done through the code. For example, assuming the only different is SPD data for these different BomIDs and you have 4 SPD data tags ( CFG_SPD1_DATA to CFG_SPD4_DATA) in the platform CFGDATA. After you get the BomId, you can add code to get different SPD configuration data tag according to its BomId. Of course, you can also use BoardId instead. We have added !include support in DLT file. Thanks Maurice From: Wim Vervoorn [mailto:wvervoorn@eltan.com] Sent: Wednesday, August 14, 2019 3:27 To: Ma, Maurice <maurice.ma@intel.com<mailto:maurice.ma@intel.com>>; sbl-devel@lists.01.org<mailto:sbl-devel@lists.01.org> Subject: RE: Improving onboard memory support Hello Maurice, Thanks for the quick feedback. Your response is clear but I do have one follow up remark. In most cases the difference between various memory configurations is very small (memory only) in these cases using the BomID sounds like the best alternative. My question now is, how do I use this? Can this only be used from the code or can I also use it using the configuration data by creating a DSC or adding it to a DLT. I haven't seen any signs of that and this mechanism only seems to use the PlatformID. My other alternative is to add the available SPD's using a DSC and using the BomID combined with a fixed table to assign the SPD's to a channel. Best Regards, Wim Vervoorn From: Ma, Maurice [mailto:maurice.ma@intel.com] Sent: Tuesday, August 13, 2019 7:40 PM To: Wim Vervoorn <wvervoorn@eltan.com<mailto:wvervoorn@eltan.com>>; sbl-devel@lists.01.org<mailto:sbl-devel@lists.01.org> Subject: RE: Improving onboard memory support Hi, Wim, For the 1st question, there are two different levels. If the boards are very different, we usually use different Board ID and handle them using DLT files to list the difference between this board and the default CFGDATA. If the boards are very close (EX: only memory configuration is different), we can use SetPlatformBomId()/GetPlatformBomId to set BOM ID using platform specific mechanism. Then code can be added in platform package to handle the difference. If you prefer using Board ID to handle the memory configuration difference, it is also OK. I think the duplication in delta files can be mitigated using include file. So these delta file can include a common file and then just list the memory configuration difference for that board. We can add "!include" support in DLT file. For the 2nd issue you mentioned, Yes, it makes perfect sense. The general guidance is to break larger configuration items into smaller TAGS so that it is easier to maintain. Since SPD data is big, we have made the SPD CFG data as separate configuration tag for some of internal projects. We will do it for open sourced CFL/WHL projects soon. Thank you for providing these valuable feedback! Thanks Maurice From: Sbl-devel [mailto:sbl-devel-bounces@lists.01.org] On Behalf Of Wim Vervoorn Sent: Tuesday, August 13, 2019 1:11 To: sbl-devel@lists.01.org<mailto:sbl-devel@lists.01.org> Subject: [Sbl-devel] Improving onboard memory support Hello, When working on a system with onboard memory I am running into a drawback of the way the SPD configuration for onboard memory systems is implemented. Please correct me if I am wrong but as I see it now the way to implement a board that can have multiple memory configurations is to assign multiple board ids and create a dlt file for each ID and integrate the SPD files for that configuration in this dlt. The first thing that I run into is that I need to duplicate all settings and update the memory configuration for this board id. Because of the duplication more maintenance is required. To resolve this it would be required to allow the board id to be split in several items so it can become more modular. For the memory case we would need a couple of bits to figure out what the memory configuration on this board is. Besides this there is another issue. If you have a board that can contains several types of memory and also have banks that are populated and others that are not we are now wasting a lot of configuration space. Each configuration is now using 2K bytes of space just because the system reserves this in the memory parameters. My suggestion would be to separate the SPD space from the remainder of the memory configuration. One area can then contain the SPD data while the MemorySpdPtr00 etc only contain a pointer to the correct SPD (0 if no spd is used, 1 for the 2nd etc). I think this would make the memory configuration for onboard memory systems much more flexible. Best Regards, Wim Vervoorn Eltan B.V. Ambachtstraat 23 5481 SM Schijndel The Netherlands T : +31-(0)73-594 46 64 E : wvervoorn@eltan.com<mailto:wvervoorn@eltan.com> W : http://www.eltan.com<http://www.eltan.com/> "THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR, PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664 OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES."