Intel Corporation

Lyle E Cool

Saul Lewites

Vincent J Zimmer

David W Grawrock

Bruce Querbach

Tieyu Zheng

Yasser Rasheed

Keshavan K Tiruvallur

Mark B Trobough

Chinna B Prudvi

Vui Yong Liew

Hermann Gartler

Ashok N Kabadi

Samie B Samaan

Keith A Drescher

Mukesh Kataria

Jay Joseph Nejedlo

James J Grealish

Russell J Wunderlich

Brian Meyer

Abhijit Davare

Priyadarsan Patra

William Penner

Rahima K Mohammed

Ridvan A Sahan

Wee Hoo Cheah

Arun R Ramadorai

Kapila B Udawatta

Yuen Tat Lee

John L Baudrexl

Loren James McConnell

Kip C Killpack

Kyle Markley

Christian E Iovin

Padmakumar Gopal

Sanjay S Salem

Travis K Goff

David C Florey

Evan J Halprin

Jiun Long Foo

Selvakumar Raja Gopal

Neil Dobler

Nagib Z Hakim

Timothy S Storey

Yi Amy Xia

Edwin E Parks

An apparatus and method is described herein for providing a test, validation, and debug architecture. At a target or base level, hardware hooks (Design for Test or DFx) are designed into and integrated with silicon parts. A controller may provide abstracted access to such hooks, such as through an abstraction layer that abstracts low level details of the hardware DFx. In addition, the abstraction layer through an interface, such as APIs, provides services, routines, and data structures to higher-level software/presentation layers, which are able to collect test data for validation and debug of a unit/platform under test. Moreover, the architecture potentially provides tiered (multiple levels of) secure access to the test architecture. Additionally, physical access to the test architecture for a platform may be simplified through use of a unified, bi-directional test access port, while also potentially allowing remote access to perform remote test and debug of a part/platform under test. In essence, a complete test architecture stack is described herein for test, validation, and debug of electronic parts, devices, and platforms.

Test, validation, and debug architecture

A processing system with multiple processing units may support separate operating systems (OSs) in separate partitions. During an initialization process, a preboot manager in the processing system may copy software to a sequestered area of memory in the processing system. The preboot manager may also configure the processing system to hide the sequestered area of memory from a first partition of the processing system. Also, the preboot manager may use a first processing unit in the processing system to boot an OS on the first partition, and the preboot manager may transmit a boot trigger from the first processing unit to a second processing unit in the processing system. The boot trigger may cause the second processing unit to use the software in the sequestered area of memory to boot a second partition of the processing system. Other embodiments are described and claimed.

Method and apparatus to support separate operating systems in partitions of a processing system

Methods and arrangements to launch trusted, distinct, co-existing environments are disclosed. Embodiments may launch trusted, distinct, co-existing environments in pre-OS space with high assurance. A hardware-enforced isolation scheme may isolate the partitions to facilitate storage and execution of code and data. In many embodiments, the system may launch a partition manager to establish embedded and main partitions. Embedded partitions may not be visible to the main OS and may host critical operations. A main partition may host a general-purpose OS and user applications, and may manage resources that are not assigned to the embedded partitions. Trustworthiness in the launch of the embedded partition is established by comparing integrity metrics for the runtime environment against integrity measurements of a trusted runtime environment for the embedded partition, e.g., by sealing a cryptographic key with the integrity metrics in a trusted platform module. Other embodiments are described and claimed.

Methods and arrangements to launch trusted, coexisting environments

Methods and arrangements to launch trusted, co-existing environments

In a many core system, receiving a call to a graphics driver; translating the call into a command executable on a core of the many core system; and executing the translated call on the core.

Graphics processing on a processor core

Method and apparatus to support independent systems in partitions of a processing system

Growing community of inventors

Beaverton, OR, United States of America

Lyle E Cool