DOCSLIB.ORG

Firmware Extension Specification Software V2.2

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Firmware Extension Specification Software V2.2 Intel® Rack Scale Design Firmware Extension Specification Software v2.2 December 19, 2017 Revision 001 Document Number: 336860-001 You may not use or facilitate the use of this document in connection with any infringement or other legal analysis concerning Intel products described herein. You agree to grant Intel a non-exclusive, royalty-free license to any patent claim thereafter drafted which includes subject matter disclosed herein. No license (express or implied, by estoppel or otherwise) to any intellectual property rights is granted by this document. Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and noninfringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade. This document contains information on products, services, and/or processes in development. All information provided here is subject to change without notice. Contact your Intel representative to obtain the latest forecast, schedule, specifications, and roadmaps. The products described may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request. Copies of documents which have an order number and are referenced in this document may be obtained by calling 1-800-548-4725 or by visiting: http://www.intel.com/design/literature.htm Intel and the Intel logo are trademarks of Intel Corporation in the U.S. and/or other countries. *Other names and brands may be claimed as the property of others. Copyright © 2017, Intel Corporation. All rights reserved. Intel® Rack Scale Design Firmware Extension Specification v2.2 December 19, 2017 2 Document Number: 336860-001 Contents 1.0 Introduction ..................................................................................................................................................................6 1.1 Terminology ........................................................................................................................................................................6 1.2 Reference Documents ..................................................................................................................................................7 2.0 Intel® Rack Scale Design IPMI Commands ..............................................................................................9 2.1 ME/SPS IPMI Commands ...........................................................................................................................................9 2.2 Rack Scale BMC IPMI Extension Commands .................................................................................................9 2.2.1 IPMI Rack Scale Extensions Commands: ................................................................ 12 3.0 SMBIOS Data Structures ..................................................................................................................................... 20 3.1 NIC Information ............................................................................................................................................................ 20 3.2 PCIe* Information ....................................................................................................................................................... 21 3.3 Processor CPUID Information ............................................................................................................................... 21 3.4 Memory Device Information .................................................................................................................................. 23 3.5 Storage Device informationg36 .......................................................................................................................... 23 3.6 Trusted Platform Module Information ............................................................................................................. 24 3.7 Intel® Trusted Execution Technology Information ............................................................................... 25 3.8 Memory Device Extended Information ........................................................................................................... 25 3.9 FPGA Information ......................................................................................................................................................... 26 3.10 Cabled PCIe* Port Information ........................................................................................................................... 28 3.11 SMBIOS Physical Device Mapping Information ......................................................................................... 29 4.0 iSCSI Boot Options Support .............................................................................................................................. 32 4.1 Overview ............................................................................................................................................................................ 32 4.2 STRING Definition ........................................................................................................................................................ 32 4.3 iSCSI Boot Options MDR Region Layout ....................................................................................................... 32 4.3.1 Version (Parameter 1) .......................................................................................................... 33 4.3.2 Initiator (Parameter 2) ........................................................................................................ 34 4.3.3 Target (Parameter 3) ............................................................................................................ 34 4.3.4 iSCSI Attempt (Parameter 4) .......................................................................................... 35 5.0 Miscellaneous Requirements ........................................................................................................................... 37 5.1 Management Network Exposure to Host OS .............................................................................................. 37 5.2 Link Layer Discovery Protocol Support .......................................................................................................... 37 Figures Figure 1. Example Connection Diagram .............................................................................................................................. 10 Intel® Rack Scale Design December 19, 2017 Firmware Extension Specification v2.2 Document Number: 336860-001 3 Tables Table 1. Terminology ........................................................................................................................................................................6 Table 2. Reference Documents ..................................................................................................................................................7 Table 3. IPMI Rack Scale Design Extensions Command Summary ................................................................. 11 Table 4. IPMI Rack Scale Extensions Command Table ............................................................................................ 12 Table 5. NIC Information SMBIOS Structure ................................................................................................................. 20 Table 6. PCI Express* (PCIe*) Information SMBIOS Structure ........................................................................ 21 Table 7. Processor CPUID SMBIOS Structure Subtype 1 ....................................................................................... 21 Table 8. Processor CPUID SMBIOS Structure Subtype 2 ....................................................................................... 22 Table 9. CPUID Data Byte Order ............................................................................................................................................ 23 Table 10. Storage Device SMBIOS Structure ................................................................................................................... 23 Table 11. TPM Information SMBIOS Structure ................................................................................................................ 24 Table 12. TXT Information SMBIOS Structure ................................................................................................................. 25 Table 13. Memory Device Extended Information SMBIOS Structure ............................................................... 25 Table 14. FPGA Information SMBIOS Structure .............................................................................................................. 26 Table 15. Cabled PCIe* Port Information SMBIOS Structure ................................................................................ 28 Table 16. SMBIOS Physical Device Mapping Table ....................................................................................................... 30 Table 17. SMBIOS Processor Physical Device Mapping Structure ....................................................................... 30 Table 18. SMBIOS PCIe System Slot Physical Device Mapping Structure ..................................................... 30 Table 19. SMBIOS Memory Physical Device Mapping Structure .........................................................................
Load more

Recommended publications
  • Data Validation As a Main Function of Business Intelligence
    E-Leader Berlin 2012 Data Validation as a Main Function of Business Intelligence PhDr. M.A. Dipl.-Betriebswirt (FH) Thomas H. Lenhard, PhD. University of Applied Sciences Kaiserslautern Campus Zweibruecken Zweibruecken, Germany Abstract Thinking about Business Intelligence, Data Mining or Data Warehousing, it seems to be clear, that we generally use three levels to compute our data into information. These levels are validation of input data, transformation and making output data available. This study/paper will give a short overview about the importance of validation and the validation level of a Data Warehouse or any BI-System. Several examples shall prove that validation is not only important to get proper and useful output data. Some combinations of circumstances will show that validation might be the result that is requested. After an introduction concerning the levels of generating information and after explaining necessary basics about BI, different methods of validation will be discussed as well as it will be thought about different variations to use the validation level or the validated data. Examples from the practice of Business Intelligence in general and in the area of Health Care IT specifically will support the theory that the level of validation must be considered as the most important. Especially in the area of operational management, it will be proven that a profound use of data validation can cause benefits or even prevent losses. Therefore it seems to be a method to increase efficiency in business and production. The Importance of Quality in Business Intelligence Business Intelligence (BI) is a non-exclusive collection of methods that are used as a transformation process to generate information out of data.
    [Show full text]
  • Complete Report
    A Report on The Fifteenth International TOVS Study Conference Maratea, Italy 4-10 October 2006 Conference sponsored by: IMAA / CNR Met Office (U.K.) University of Wisconsin-Madison / SSEC NOAA NESDIS EUMETSAT World Meteorological Organization ITT Industries Kongsberg Spacetec CNES ABB Bomem Dimension Data LGR Impianti Cisco Systems and VCS Report prepared by: Thomas Achtor and Roger Saunders ITWG Co-Chairs Leanne Avila Maria Vasys Editors Published and Distributed by: University of Wisconsin-Madison 1225 West Dayton Street Madison, WI 53706 USA ITWG Web Site: http://cimss.ssec.wisc.edu/itwg/ February 2007 International TOVS Study Conference-XV Working Group Report FOREWORD The International TOVS Working Group (ITWG) is convened as a sub-group of the International Radiation Commission (IRC) of the International Association of Meteorology and Atmospheric Physics (IAMAP). The ITWG continues to organise International TOVS Study Conferences (ITSCs) which have met approximately every 18 months since 1983. Through this forum, operational and research users of TIROS Operational Vertical Sounder (TOVS), Advanced TOVS (ATOVS) and other atmospheric sounding data have exchanged information on data processing methods, derived products, and the impacts of radiances and inferred atmospheric temperature and moisture fields on numerical weather prediction (NWP) and climate studies. The Fifteenth International TOVS Study Conference (ITSC-XV) was held at the Villa del Mare near Maratea, Italy from 4 to 10 October 2006. This conference report summarises the scientific exchanges and outcomes of the meeting. A companion document, The Technical Proceedings of The Fourteenth International TOVS Study Conference, contains the complete text of ITSC-XV scientific presentations. The ITWG Web site ( http://cimss.ssec.wisc.edu/itwg/ ) contains electronic versions of the conference presentations and publications.
    [Show full text]
  • Ssfm BPG 1: Validation of Software in Measurement Systems
    NPL Report DEM-ES 014 Software Support for Metrology Best Practice Guide No. 1 Validation of Software in Measurement Systems Brian Wichmann, Graeme Parkin and Robin Barker NOT RESTRICTED January 2007 National Physical Laboratory Hampton Road Teddington Middlesex United Kingdom TW11 0LW Switchboard 020 8977 3222 NPL Helpline 020 8943 6880 Fax 020 8943 6458 www.npl.co.uk Software Support for Metrology Best Practice Guide No. 1 Validation of Software in Measurement Systems Brian Wichmann with Graeme Parkin and Robin Barker Mathematics and Scientific Computing Group January 2007 ABSTRACT The increasing use of software within measurement systems implies that the validation of such software must be considered. This Guide addresses the validation both from the perspective of the user and the supplier. The complete Guide consists of a Management Overview and a Technical Application together with consideration of its use within safety systems. Version 2.2 c Crown copyright 2007 Reproduced with the permission of the Controller of HMSO and Queen’s Printer for Scotland ISSN 1744–0475 National Physical Laboratory, Hampton Road, Teddington, Middlesex, United Kingdom TW11 0LW Extracts from this guide may be reproduced provided the source is acknowledged and the extract is not taken out of context We gratefully acknowledge the financial support of the UK Department of Trade and Industry (National Measurement System Directorate) Approved on behalf of the Managing Director, NPL by Jonathan Williams, Knowledge Leader for the Electrical and Software team Preface The use of software in measurement systems has dramatically increased in the last few years, making many devices easier to use, more reliable and more accurate.
    [Show full text]
  • Review Article Applied Machine Learning and Artificial Intelligence in Rheumatology
    Rheumatology Advances in Practice 20;0:1–10 Rheumatology Advances in Practice doi:10.1093/rap/rkaa005 Review article Applied machine learning and artificial intelligence in rheumatology Maria Hu¨ gle1, Patrick Omoumi2, Jacob M. van Laar3, Joschka Boedecker1,* and Thomas Hu¨ gle4,* Abstract Machine learning as a field of artificial intelligence is increasingly applied in medicine to assist patients and physicians. Growing datasets provide a sound basis with which to apply machine learning meth- ods that learn from previous experiences. This review explains the basics of machine learning and its subfields of supervised learning, unsupervised learning, reinforcement learning and deep learning. We provide an overview of current machine learning applications in rheumatology, mainly supervised learn- ing methods for e-diagnosis, disease detection and medical image analysis. In the future, machine learning will be likely to assist rheumatologists in predicting the course of the disease and identifying important disease factors. Even more interestingly, machine learning will probably be able to make treatment propositions and estimate their expected benefit (e.g. by reinforcement learning). Thus, in fu- ture, shared decision-making will not only include the patient’s opinion and the rheumatologist’s empir- ical and evidence-based experience, but it will also be influenced by machine-learned evidence. Key words: machine learning, neural networks, deep learning, rheumatology, artificial intelligence Key messages . Deep learning can assist rheumatologists by disease classification and prediction of individual disease activity. Artificial intelligence has the potential to empower autonomy of patients, e.g. by providing individual treatment propositions. Automated image recognition and natural language processing will be likely to pioneer implementation of artificial intelligence in rheumatology.
    [Show full text]
  • Data Migration
    Science and Technology 2018, 8(1): 1-10 DOI: 10.5923/j.scit.20180801.01 Data Migration Simanta Shekhar Sarmah Business Intelligence Architect, Alpha Clinical Systems, USA Abstract This document gives the overview of all the process involved in Data Migration. Data Migration is a multi-step process that begins with an analysis of the legacy data and culminates in the loading and reconciliation of data into new applications. With the rapid growth of data, organizations are in constant need of data migration. The document focuses on the importance of data migration and various phases of it. Data migration can be a complex process where testing must be conducted to ensure the quality of the data. Testing scenarios on data migration, risk involved with it are also being discussed in this article. Migration can be very expensive if the best practices are not followed and the hidden costs are not identified at the early stage. The paper outlines the hidden costs and also provides strategies for roll back in case of any adversity. Keywords Data Migration, Phases, ETL, Testing, Data Migration Risks and Best Practices Data needs to be transportable from physical and virtual 1. Introduction environments for concepts such as virtualization To avail clean and accurate data for consumption Migration is a process of moving data from one Data migration strategy should be designed in an effective platform/format to another platform/format. It involves way such that it will enable us to ensure that tomorrow’s migrating data from a legacy system to the new system purchasing decisions fully meet both present and future without impacting active applications and finally redirecting business and the business returns maximum return on all input/output activity to the new device.
    [Show full text]
  • DS18B20 Datasheet
    AVAILABLE DS18B20 Programmable Resolution 1-Wire Digital Thermometer DESCRIPTION . User-Definable Nonvolatile (NV) Alarm The DS18B20 digital thermometer provides 9-bit Settings to 12-bit Celsius temperature measurements and . Alarm Search Command Identifies and has an alarm function with nonvolatile user- Addresses Devices Whose Temperature is programmable upper and lower trigger points. Outside Programmed Limits (Temperature The DS18B20 communicates over a 1-Wire bus Alarm Condition) that by definition requires only one data line (and . Available in 8-Pin SO (150 mils), 8-Pin µSOP, ground) for communication with a central and 3-Pin TO-92 Packages microprocessor. It has an operating temperature . Software Compatible with the DS1822 range of -55°C to +125°C and is accurate to . Applications Include Thermostatic Controls, ±0.5°C over the range of -10°C to +85°C. In Industrial Systems, Consumer Products, addition, the DS18B20 can derive power directly Thermometers, or Any Thermally Sensitive from the data line (“parasite power”), eliminating System the need for an external power supply. PIN CONFIGURATIONS Each DS18B20 has a unique 64-bit serial code, which allows multiple DS18B20s to function on the same 1-Wire bus. Thus, it is simple to use one MAXIM microprocessor to control many DS18B20s N.C. 1 8 N.C. 18B20 MAXIM 18B20 distributed over a large area. Applications that N.C. 2 7 N.C. can benefit from this feature include HVAC 1 2 3 environmental controls, temperature monitoring VDD 3 6 N.C. systems inside buildings, equipment, or DQ 4 5 GND machinery, and process monitoring and control systems.
    [Show full text]
  • 17.0 Data Review, Verification and Validation
    QA Handbook Vol II, Section 17.0 Revision No: 1 Date: 12/08 Page 1 of 7 17.0 Data Review, Verification and Validation Data review, verification and validation are techniques used to accept, reject or qualify data in an objective and consistent manner. Verification can be defined as confirmation, through provision of objective evidence that specified requirements have been fulfilled1. Validation can be defined as confirmation through provision of objective evidence that the particular requirements for a specific intended use are fulfilled. It is important to describe the criteria for deciding the degree to which each data item has met its quality specifications as described in an organization’s QAPP. This section will describe the techniques used to make these assessments. In general, these assessment activities are performed by persons implementing the environmental data operations as well as by personnel “independent” of the operation, such as the organization’s QA personnel and at some specified frequency. The procedures, personnel and frequency of the assessments should be included in an organization’s QAPP. These activities should occur prior to submitting data to AQS and prior to final data quality assessments that will be discussed in Section 18. Each of the following areas of discussion should be considered during the data review/verification/validation processes. Some of the discussion applies to situations in which a sample is separated from its native environment and transported to a laboratory for analysis and data generation; others are applicable to automated instruments. The following information is an excerpt from EPA G-52: Sampling Design - How closely a measurement represents the actual environment at a given time and location is a complex issue that is considered during development of the sampling design.
    [Show full text]
  • Introduction to Data Validation (PDF)
    Introduction to Data Validation Hilary Hafner Sonoma Technology, Inc. Petaluma, CA for National Ambient Air Monitoring Conference St. Louis, MO August 8, 2016 STI-6550 2 VOC and PM Speciation Data • Differences from one measurement (such as ozone or PM mass) – More complex instruments (more to go wrong?) – Many species per sample – Data overload • Opportunity for intercomparison 3 Why You Should Validate Your Data (1) • It is the monitoring agency’s responsibility to prevent, identify, correct, and define the consequences of monitoring difficulties that might affect the precision and accuracy, and/or the validity, of the measurements. • Serious errors in data analysis and modeling (and subsequent policy development) can be caused by erroneous data values. • Accurate information helps you respond to community concerns. Validate data as soon after collection as practical – it reduces effort and minimizes data loss 4 Why You Should Validate Your Data (2) • Criteria pollutant data quality issues are important to national air quality management actions, including – Attainment/nonattainment designations – Clean data determinations – Petitions to EPA for reconsideration • Air quality data are very closely reviewed by stakeholders – Do data collection efforts meet all CFR requirements? – Have procedures outlined in the QA handbook or project-specific QA plans been followed? – Are agency logbooks complete and up-to-date? • Deviations are subject to potential litigation From Weinstock L. (2014) Ambient Monitoring Update. Presented at the National Ambient Air Monitoring Conference, Atlanta, GA, August 11-14, by the U.S. Environmental Protection Agency Office of Air Quality Planning and Standards. Available at https://www3.epa.gov/ttnamti1/files/2014conference/tueweinstock.pdf.
    [Show full text]
  • Auto-Validate: Unsupervised Data Validation Using Data-Domain Patterns Inferred from Data Lakes
    Auto-Validate: Unsupervised Data Validation Using Data-Domain Patterns Inferred from Data Lakes Jie Song∗ Yeye He University of Michigan Microsoft Research [email protected] [email protected] ABSTRACT Complex data pipelines are increasingly common in diverse ap- plications such as BI reporting and ML modeling. These pipelines often recur regularly (e.g., daily or weekly), as BI reports need to be refreshed, and ML models need to be retrained. However, it is widely reported that in complex production pipelines, upstream data feeds can change in unexpected ways, causing downstream applications to break silently that are expensive to resolve. Figure 1: Example code snippet to describe expected data- Data validation has thus become an important topic, as evidenced values, using declarative constraints in Amazon Deequ. by notable recent efforts from Google and Amazon, where the ob- jective is to catch data quality issues early as they arise in the pipelines. Our experience on production data suggests, however, Such schema-drift and data-drift can lead to quality issues in that on string-valued data, these existing approaches yield high downstream applications, which are both hard to detect (e.g., mod- false-positive rates and frequently require human intervention. In est model degradation due to unseen data [53]), and hard to debug this work, we develop a corpus-driven approach to auto-validate (finding root-causes in complex pipelines can be difficult). These machine-generated data by inferring suitable data-validation “pat- silent failures require substantial human efforts to resolve, increas- terns” that accurately describe the underlying data-domain, which ing the cost of running production data pipelines and decreasing minimizes false-positives while maximizing data quality issues the effectiveness of data-driven system [21, 53, 58, 60].
    [Show full text]
  • Efficient Compression of PMU Data in WAMS
    IEEE TRANSACTIONS ON SMART GRID, SPECIAL ISSUE ON BIG DATA ANALYTICS FOR GRID MODERNIZATION Efficient Compression of PMU Data in WAMS Phani Harsha Gadde, Student Member, IEEE, Milan Biswal, Member, IEEE, Sukumar Brahma, Senior Member, IEEE, and Huiping Cao Abstract—Widespread placement and high data sampling rate Archived data can be used for purposes like model validation, of current generation of Phasor Measurement Units (PMUs) in testing new wide area protection and control applications Wide Area Monitoring Systems (WAMS) result in huge amount that use PMU data, or training/testing disturbance classifiers of data to be analyzed and stored, making efficient storage of such data a priority. This paper presents a generalized compression typically used in system visualization applications that are technique that utilizes the inherent correlation within PMU being commercialized. data by exploiting both spatial and temporal redundancies. A Clearly, compression methods are necessary to archive these two stage compression algorithm is proposed using Principal data. Such methods essentially seek to maximize the Com- Component Analysis in the first stage, and Discrete Cosine pression Ratio (CR), and minimize the loss of data, which is Transform in the second. Since compression parameters need to be adjusted to compress critical disturbance information with measured by certain error metrics. The parameters chosen for high fidelity, an automated but simple statistical change detection any compression technique heavily depend on the nature of the technique is proposed to identify disturbance data. Extensive data. In case of PMU data, most of the data will be relatively verifications are performed using field data as well as simulated constant or slow-varying with overriding noise, but in case of data to establish generality and superior performance of the a disturbance the data will vary.
    [Show full text]
  • "Data Validation". In: Clinical Data Management
    SEQ 0014 JOB PDF8280-006-007 PAGE-0109 CHAP 6 109-122 REVISED 30NOV01 AT 16:46 BY TF DEPTH: 58.01 PICAS WIDTH 40 PICAS Clinical Data Management, 2nd Edition. Richard K. Rondel, Sheila A. Varley, Colin F. Webb Copyright 1993, 2000 John Wiley & Sons Ltd ISBNs: 0471-98329-2 (Hardback); 0470-84636-4 (Electronic) 6 Data Validation PANKAJ ‘PANNI’ PATEL SmithKline Beecham Pharmaceuticals, Harlow, Essex, UK INTRODUCTION The primary objective of Clinical Data Management (CDM) is to ensure timely delivery of high-quality data which are necessary to satisfy both good clinical practice (GCP) requirements and the statistical analysis and reporting requirements. CDM data validation activities play a critical role within the drug development programme involving many people, multiple systems and several data transfers. The quality of the data validation process has a direct impact on the quality of data presented as part of an NDA submission. There is a general misconception that data validation activities com- mence when clinical trial data are presented to the sponsor’s data man- agement department. The author will attempt to dispel this somewhat narrow view and discuss various stages of data validation activities which actually start when the investigator records the data on the case report form (CRF) and when the final medical report is issued as part of the overall clinical trial data handing and reporting process. CDM REQUIREMENT IN GCP CDM requirements within the ICH and EU CPMP GCP guidelines are not defined in any great detail, resulting in lack of clarity, or indeed misrepre- sentation. The FDA Code of Federal Regulations contains no mention of CDM! This should be considered as a major concern, given that CDM plays a vital role in protecting data integrity, and is charged with produc- ing high-quality databases that meet clinical and regulatory require- ments.
    [Show full text]
  • EDRM Glossary Version 1.002, April 22, 2016
    EDRM Glossary http://www.edrm.net/resources/glossaries/glossary Version 1.002, April 22, 2016 © 2016 EDRM LLC EDRM Glossary http://www.edrm.net/resources/glossaries/glossary The EDRM Glossary is EDRM's most comprehensive listing of electronic discovery terms. It includes terms from the specialized glossaries listed below as well as terms not in those glossaries. The terms are listed in alphabetical order with definitions and attributions where available. EDRM Collection Standards Glossary The EDRM Collection Standards Glossary is a glossary of terms defined as part of the EDRM Collection Standards. EDRM Metrics Glossary The EDRM Metrics Glossary contains definitions for terms used in connection with the updated EDRM Metrics Model published in June 2013. EDRM Search Glossary The EDRM Search Glossary is a list of terms related to searching ESI. EDRM Search Guide Glossary The EDRM Search Guide Glossary is part of the EDRM Search Guide. The EDRM Search Guide focuses on the search, retrieval and production of ESI within the larger e- discovery process described in the EDRM Model. IGRM Glossary The IGRM Glossary consists of commonly used Information Governance terms. The Grossman-Cormack Glossary of Technology-Assisted Review Developed by Maura Grossman of Wachtell, Lipton, Rosen & Katz and Gordon Cormack of the University of Waterloo, the Grossman-Cormack Glossary of Technology-Assisted Review contains definitions for terms used in connect with the discovery processes referred to by various terms including Computer Assisted Review, Technology Assisted Review, and Predictive Coding. If you would like to submit a new term with definition or a new definition for an existing term, please go to our Submit a Definition page, http://www.edrm.net/23482, and complete and submit the form.
    [Show full text]