Marshall Dawson has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/33399
Change subject: Documentation/soc/amd: Add picasso ......................................................................
Documentation/soc/amd: Add picasso
Begin a directory for AMD soc devices and add an explanation of how picasso, the first Family 17h offering in coreboot, works. Family 17h represents a unique paradigm for initializing x86 processors due to the work offloaded to the PSP, and the system state at the time of x86 first fetch.
Change-Id: I7bd8649996add80747f6a60b9dfd35a94a560be1 Signed-off-by: Marshall Dawson marshalldawson3rd@gmail.com --- A Documentation/soc/amd/index.md A Documentation/soc/amd/picasso/family17h.md M Documentation/soc/index.md 3 files changed, 131 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/99/33399/1
diff --git a/Documentation/soc/amd/index.md b/Documentation/soc/amd/index.md new file mode 100644 index 0000000..6f42d87 --- /dev/null +++ b/Documentation/soc/amd/index.md @@ -0,0 +1,7 @@ +# AMD SOC-specific documentation + +This section contains documentation about coreboot on specific AMD SOCs. + +## Platforms + +- [Picasso/Family 17h](picasso/family17h.md) diff --git a/Documentation/soc/amd/picasso/family17h.md b/Documentation/soc/amd/picasso/family17h.md new file mode 100755 index 0000000..6df3ae3 --- /dev/null +++ b/Documentation/soc/amd/picasso/family17h.md @@ -0,0 +1,123 @@ +# AMD Family 17h in coreboot + +## Abstract + +Beginning with Family 17h products (a.k.a. “Zen” cores), AMD changed their paradigm for initializing the system and this requires major modifications to the execution flow of coreboot. This file discusses the new boot flow, and challenges, and the tradeoffs of the initial port into coreboot. + +## Introduction + +Family 17h products are x86-based designs. This documentation assumes familiarity with x86, its reset state and its early initialization requirements. + +To the extent necessary, the role of the Platform Security Processor (a.k.a. PSP) in system initialization is addressed here. AMD has historically required an NDA for access to the PSP specification<sup>1</sup>. coreboot relies on util/amdfwtool to build the structures and add various other firmware to the final image. The Family 17h PSP design guide adds a new BIOS Directory Table, similar to the PSP Directory Table. + +Support in coreboot for modern AMD products is based on AMD’s reference code: AMD Generic Encapsulated Software Architecture (AGESA<sup>TM</sup>). AGESA contains the technology for enabling DRAM, configuring proprietary core logic, assistance with generating ACPI tables, and other features. + +AGESA for products earlier than Family 17h is known as v5 or Arch2008<sup>2</sup>. Also note that coreboot currently contains both open source AGESA and closed source implementations (binaryPI) compiled from AGESA. + +The first AMD Family 17h device ported to coreboot is codenamed “Picasso”<sup>3</sup>, and will be added to soc/amd/picasso. + +## Additional Definitions + +* PSP, Platform Security Processor: Onboard ARM processor that runs alongside the main x86 processor; may be viewed as analogous to the Intel<sup>R</sup> Management Engine +* FCH, Fusion Control Hub, the logical southbridge within the SOC +* ABL - AGESA Bootloader - Processor initialization code that runs on the PSP +* PSP Directory Table - A structured list of pointers to PSP firmware and other controller binaries +* BIOS Directory Table - A structured list of pointers to BIOS related firmware images +* Embedded Firmware Structure - Signature and pointers used by the PSP to locate the PSP Directory Table and BIOS Directory Table; these items are generated during coreboot build and are located in the SPI ROM +* Verstage - The code to verify the firmware contained in the writable section of the SPI ROM +* APCB - AMD PSP Customization Block - A binary containing PSP and system configuration preferences (analogous to v5 BUILDOPT_ options), and generated by APCBTool to be added to coreboot/utils later +* APOB - AGESA PSP Output Buffer - A buffer in main memory for storing AGESA BootLoader output. There are no plans for this to be parsed by coreboot + +## Problem Statements + +AMD has ported early AGESA features to the PSP, which now discovers, enables and trains DRAM. Unlike any other x86 device in coreboot, a Picasso system has DRAM online prior to the first instruction fetch. + +Cache-as-RAM (CAR) is no longer a supportable feature in AMD hardware. Early code expecting CAR behavior <span style="text-decoration:underline;">must</span> account for writes escaping the L2 cache and going to DRAM. + +Without any practical need for CAR, or DRAM initialization, coreboot should arguably skip bootblock and romstage, and possibly use ramstage as the BIOS image. This approach presents a number of challenges: + +* At the entry of ramstage, x86 processors are in flat protected mode. Picasso’s initial state is nearly identical to any other x86 at reset, except its CS shadow register’s base and limit put its execution within DRAM, not at 0xfffffff0. Picasso requires initial programming and entry into protected mode prior to ramstage. +* coreboot expects cbmem initialization during romstage. + +AGESA supporting Picasso is now at v9. Unlike Arch2008, which defines granular entry points for easy inclusion to a legacy BIOS, v9 is rewritten for compilation into a UEFI. The source follows UEFI standards, i.e. assumes the presence of UEFI phases, implements dependency expressions, much functionality is rewritten as libraries, etc. It would, in no way, fit into the v5 model used in coreboot. + +* For the foreseeable future, AGESA source will distributed only under NDA. + +## Basic Pre-x86 Boot Flow + +The following steps occur prior to x86 processor operation. + +* System power on +* PSP executes immutable on-chip boot ROM +* PSP locates the Embedded Firmware Table and PSP Directory Table in the SPI ROM +* PSP verifies and executes the PSP off-chip bootloader +* ChromeOS systems: + * Off-chip bootloader attempts to locate verstage via the RO BIOS Directory Table + * If verstage is not found, booting continues with ABLs below + * Verstage initializes, setting up GPIOs, UART if needed, communication path to the EC, and the SPI controller for direct access to the flash device. + * Verstage verifies the RW sections (as is typically performed by the main processor) + * Verstage locates the Embedded Firmware Directory within the verified FMAP section and passes a pointer to the PSP bootloader. If the verification fails, it passes a pointer to the RO header to the bootloader. +* PSP parses the PSP Directory Table to find the ABLs and executes them +* An ABL parses the APCB for system configuration preferences +* An ABL initializes system main memory, locates the compressed BIOS image in the SPI ROM, and decompresses it into DRAM +* An ABL writes the APOB to DRAM for consumption by the x86-based AGESA +* PSP releases the x86 processor from reset. The x86 core fetches and executes instructions from the reset vector + +## Picasso Reset Vector and First Instructions + +As mentioned above, prior to releasing the x86 main core from reset, the PSP decompresses a BIOS image into DRAM. The PSP uses a specific BIOS Directory Table entry type to determine the source address (in flash), the destination address (in DRAM), and the destination size. The decompressed image is at the top of the destination region. The PSP then + +Calculates the x86 reset vector as + + reset_vector = dest_addr + dest_size - 0x10 + +Sets x86 CS descriptor shadow register to + + base = dest_addr + dest_size - 0x10000 + limit = 0xffff + +Like all x86 devices, the main core is allowed to begin executing instructions with + + CS:IP = 0xf000:0xfff0 + +For example, assume the BIOS Directory Table indicates + + destination = 0x9b00000 + size = 0x300000 + +… then the BIOS image is placed at the topmost position the region 0x9b00000-0x9dfffff and + + reset_vector = 0x9dffff0 + CS_shdw_base = 0x9df0000 + CS:IP = 0xf000:0xfff0 + +Although the x86 behaves as though it began executing at 0xfffffff0 i.e. 0xf000:0xfff0, the initial GDT load must use the physical address of the table and not the typical CS-centric address. And, the first jump to protected mode must jump to the physical address in DRAM. Any code that is position-dependent must be linked to run at the final destination. + +## Initial coreboot Implementation + +Supporting Picasso doesn’t fit well with many of the coreboot assumptions. Initial porting shall attempt to fit within existing coreboot paradigms and make minimal changes to common code. + +### CAR and bootblock + +The coreboot bootblock contains features Picasso doesn’t require or can’t use, and is assumed to execute in an unusable location. Picasso’s requirement for bootblock in coreboot will be eliminated. + +### Hybrid romstage + +Picasso’s x86 reset state doesn’t meet the coreboot expectations for jumping directly to ramstage. The primary feature of romstage is also not needed, however there are other important features that are typically in romstage that Picasso does need. + +The romstage architecture is designed around the presence of CAR. Several features implement ROMSTAGE_CBMEM_INIT_HOOK, expecting to move data from CAR to cbmem. The hybrid romstage consumes DRAM for the purpose of implementing the expected CAR storage. This region as well as the DRAM where romstage is decompressed must be reserved and unavailable to the OS. + +The initial Picasso port implements a hybrid romstage that contains the first instruction fetched at the reset vector. It minimally configures flat protected mode, initializes cbmem, then loads the next stage. Future work will consider breaking the dependencies mentioned above and/or potentially loading ramstage directly from the PSP. + +## AGESA v9 on Picasso + +Due to the current inability to publish AGESA source, a pre-built binary solution remains a requirement. The rewrite from v5 to v9 for direct inclusion into UEFI source makes modifying it for conforming to the existing v5 interface impractical. + +Given the UEFI nature of modern AGESA, and the existing open source work from Intel, Picasso shall support AGESA via an FSP-like prebuilt image. The Intel Firmware Support Package<sup>4</sup> combines reference code with EDK II source to create a modular image with discoverable entry points. coreboot source already contains knowledge of FSP, how to parse it, integrate it, and how to communicate with it. + +## Footnotes + +1. “AMD Platform Security Processor BIOS Architecture Design Guide for AMD Family 17h Processors” (PID #55758) and “AMD Platform Security Processor BIOS Architecture Design Guide” (PID #54267) for earlier products +2. [https://www.amd.com/system/files/TechDocs/44065_Arch2008.pdf%5D(https://www....) +3. [https://en.wikichip.org/wiki/amd/cores/picasso%5D(https://en.wikichip.org/wi...) +4. [https://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-s...) diff --git a/Documentation/soc/index.md b/Documentation/soc/index.md index 04e2b2f..fccddbd 100644 --- a/Documentation/soc/index.md +++ b/Documentation/soc/index.md @@ -4,5 +4,6 @@
## Vendor
+- [AMD](amd/index.md) - [Cavium](cavium/index.md) - [Intel](intel/index.md)
Martin Roth has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/33399 )
Change subject: Documentation/soc/amd: Add picasso ......................................................................
Patch Set 1:
(1 comment)
I was initially thinking it should go in Documentation/soc/amd since it will probably apply to more processors than just picasso in the future, but I guess we can update it when the next family 17h processor is added.
https://review.coreboot.org/#/c/33399/1/Documentation/soc/amd/picasso/family... File Documentation/soc/amd/picasso/family17h.md:
https://review.coreboot.org/#/c/33399/1/Documentation/soc/amd/picasso/family... PS1, Line 5: Beginning with Family 17h products (a.k.a. “Zen” cores), AMD changed their paradigm for initializing the system and this requires major modifications to the execution flow of coreboot. This file discusses the new boot flow, and challenges, and the tradeoffs of the initial port into coreboot. The text to be wrapped at 72 characters: https://doc.coreboot.org/getting_started/writing_documentation.html#basic-an...
from the command line, try:
fold -w 72 -s family17h.md
Hello build bot (Jenkins), Martin Roth,
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/coreboot/+/33399
to look at the new patch set (#2).
Change subject: Documentation/soc/amd: Add picasso ......................................................................
Documentation/soc/amd: Add picasso
Begin a directory for AMD soc devices and add an explanation of how Family 17h works. Newer AMD systems use a unique paradign for initializing the x86 processors.
Change-Id: I7bd8649996add80747f6a60b9dfd35a94a560be1 Signed-off-by: Marshall Dawson marshalldawson3rd@gmail.com --- A Documentation/soc/amd/family17h.md A Documentation/soc/amd/index.md M Documentation/soc/index.md 3 files changed, 233 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/99/33399/2
Marshall Dawson has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/33399 )
Change subject: Documentation/soc/amd: Add picasso ......................................................................
Patch Set 2:
(1 comment)
Patch Set 1:
(1 comment)
I was initially thinking it should go in Documentation/soc/amd since it will probably apply to more processors than just picasso in the future, but I guess we can update it when the next family 17h processor is added.
NP, I was on the fence but wanted it to be the most clear.
https://review.coreboot.org/#/c/33399/1/Documentation/soc/amd/picasso/family... File Documentation/soc/amd/picasso/family17h.md:
https://review.coreboot.org/#/c/33399/1/Documentation/soc/amd/picasso/family... PS1, Line 5: Beginning with Family 17h products (a.k.a. “Zen” cores), AMD changed their paradigm for initializing the system and this requires major modifications to the execution flow of coreboot. This file discusses the new boot flow, and challenges, and the tradeoffs of the initial port into coreboot.
The text to be wrapped at 72 characters: […]
Done
Hello build bot (Jenkins), Martin Roth,
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/coreboot/+/33399
to look at the new patch set (#3).
Change subject: Documentation/soc/amd: Add Family 17h ......................................................................
Documentation/soc/amd: Add Family 17h
Begin a directory for AMD soc devices and add an explanation of how Family 17h works. Newer AMD systems use a unique paradign for initializing the x86 processors.
Change-Id: I7bd8649996add80747f6a60b9dfd35a94a560be1 Signed-off-by: Marshall Dawson marshalldawson3rd@gmail.com --- A Documentation/soc/amd/family17h.md A Documentation/soc/amd/index.md M Documentation/soc/index.md 3 files changed, 233 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/99/33399/3
Martin Roth has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/33399 )
Change subject: Documentation/soc/amd: Add Family 17h ......................................................................
Patch Set 3: Code-Review+2
Martin Roth has submitted this change and it was merged. ( https://review.coreboot.org/c/coreboot/+/33399 )
Change subject: Documentation/soc/amd: Add Family 17h ......................................................................
Documentation/soc/amd: Add Family 17h
Begin a directory for AMD soc devices and add an explanation of how Family 17h works. Newer AMD systems use a unique paradign for initializing the x86 processors.
Change-Id: I7bd8649996add80747f6a60b9dfd35a94a560be1 Signed-off-by: Marshall Dawson marshalldawson3rd@gmail.com Reviewed-on: https://review.coreboot.org/c/coreboot/+/33399 Tested-by: build bot (Jenkins) no-reply@coreboot.org Reviewed-by: Martin Roth martinroth@google.com --- A Documentation/soc/amd/family17h.md A Documentation/soc/amd/index.md M Documentation/soc/index.md 3 files changed, 233 insertions(+), 0 deletions(-)
Approvals: build bot (Jenkins): Verified Martin Roth: Looks good to me, approved
diff --git a/Documentation/soc/amd/family17h.md b/Documentation/soc/amd/family17h.md new file mode 100755 index 0000000..dc3de13 --- /dev/null +++ b/Documentation/soc/amd/family17h.md @@ -0,0 +1,224 @@ +# AMD Family 17h in coreboot + +## Abstract + +Beginning with Family 17h products (a.k.a. “Zen” cores), AMD +changed their paradigm for initializing the system and this requires +major modifications to the execution flow of coreboot. This file +discusses the new boot flow, and challenges, and the tradeoffs of the +initial port into coreboot. + +## Introduction + +Family 17h products are x86-based designs. This documentation assumes +familiarity with x86, its reset state and its early initialization +requirements. + +To the extent necessary, the role of the Platform Security Processor +(a.k.a. PSP) in system initialization is addressed here. AMD has +historically required an NDA for access to the PSP +specification<sup>1</sup>. coreboot relies on util/amdfwtool to build +the structures and add various other firmware to the final image. The +Family 17h PSP design guide adds a new BIOS Directory Table, similar to +the PSP Directory Table. + +Support in coreboot for modern AMD products is based on AMD’s +reference code: AMD Generic Encapsulated Software Architecture +(AGESA<sup>TM</sup>). AGESA contains the technology for enabling DRAM, +configuring proprietary core logic, assistance with generating ACPI +tables, and other features. + +AGESA for products earlier than Family 17h is known as v5 or +Arch2008<sup>2</sup>. Also note that coreboot currently contains both +open source AGESA and closed source implementations (binaryPI) compiled +from AGESA. + +The first AMD Family 17h device ported to coreboot is codenamed +“Picasso”<sup>3</sup>, and will be added to soc/amd/picasso. + +## Additional Definitions + +* PSP, Platform Security Processor: Onboard ARM processor that runs +alongside the main x86 processor; may be viewed as analogous to the +Intel<sup>R</sup> Management Engine +* FCH, Fusion Control Hub, the logical southbridge within the SOC +* ABL - AGESA Bootloader - Processor initialization code that runs on +the PSP +* PSP Directory Table - A structured list of pointers to PSP firmware +and other controller binaries +* BIOS Directory Table - A structured list of pointers to BIOS +related firmware images +* Embedded Firmware Structure - Signature and pointers used by the +PSP to locate the PSP Directory Table and BIOS Directory Table; these +items are generated during coreboot build and are located in the SPI ROM +* Verstage - The code to verify the firmware contained in the +writable section of the SPI ROM +* APCB - AMD PSP Customization Block - A binary containing PSP and +system configuration preferences (analogous to v5 BUILDOPT_ options), +and generated by APCBTool to be added to coreboot/utils later +* APOB - AGESA PSP Output Buffer - A buffer in main memory for +storing AGESA BootLoader output. There are no plans for this to be +parsed by coreboot + +## Problem Statements + +AMD has ported early AGESA features to the PSP, which now discovers, +enables and trains DRAM. Unlike any other x86 device in coreboot, a +Picasso system has DRAM online prior to the first instruction fetch. + +Cache-as-RAM (CAR) is no longer a supportable feature in AMD hardware. +Early code expecting CAR behavior <span +style="text-decoration:underline;">must</span> account for writes +escaping the L2 cache and going to DRAM. + +Without any practical need for CAR, or DRAM initialization, coreboot +should arguably skip bootblock and romstage, and possibly use ramstage +as the BIOS image. This approach presents a number of challenges: + +* At the entry of ramstage, x86 processors are in flat protected +mode. Picasso’s initial state is nearly identical to any other x86 +at reset, except its CS shadow register’s base and limit put its +execution within DRAM, not at 0xfffffff0. Picasso requires initial +programming and entry into protected mode prior to ramstage. +* coreboot expects cbmem initialization during romstage. + +AGESA supporting Picasso is now at v9. Unlike Arch2008, which defines +granular entry points for easy inclusion to a legacy BIOS, v9 is +rewritten for compilation into a UEFI. The source follows UEFI +standards, i.e. assumes the presence of UEFI phases, implements +dependency expressions, much functionality is rewritten as libraries, +etc. It would, in no way, fit into the v5 model used in coreboot. + +* For the foreseeable future, AGESA source will distributed only +under NDA. + +## Basic Pre-x86 Boot Flow + +The following steps occur prior to x86 processor operation. + +* System power on +* PSP executes immutable on-chip boot ROM +* PSP locates the Embedded Firmware Table and PSP Directory Table in +the SPI ROM +* PSP verifies and executes the PSP off-chip bootloader +* ChromeOS systems: + * Off-chip bootloader attempts to locate verstage via the RO BIOS +Directory Table + * If verstage is not found, booting continues with ABLs below + * Verstage initializes, setting up GPIOs, UART if needed, +communication path to the EC, and the SPI controller for direct access +to the flash device. + * Verstage verifies the RW sections (as is typically performed by +the main processor) + * Verstage locates the Embedded Firmware Directory within the +verified FMAP section and passes a pointer to the PSP bootloader. If +the verification fails, it passes a pointer to the RO header to the +bootloader. +* PSP parses the PSP Directory Table to find the ABLs and executes +them +* An ABL parses the APCB for system configuration preferences +* An ABL initializes system main memory, locates the compressed BIOS +image in the SPI ROM, and decompresses it into DRAM +* An ABL writes the APOB to DRAM for consumption by the x86-based +AGESA +* PSP releases the x86 processor from reset. The x86 core fetches +and executes instructions from the reset vector + +## Picasso Reset Vector and First Instructions + +As mentioned above, prior to releasing the x86 main core from reset, +the PSP decompresses a BIOS image into DRAM. The PSP uses a specific +BIOS Directory Table entry type to determine the source address (in +flash), the destination address (in DRAM), and the destination size. +The decompressed image is at the top of the destination region. The +PSP then + +Calculates the x86 reset vector as + + reset_vector = dest_addr + dest_size - 0x10 + +Sets x86 CS descriptor shadow register to + + base = dest_addr + dest_size - 0x10000 + limit = 0xffff + +Like all x86 devices, the main core is allowed to begin executing +instructions with + + CS:IP = 0xf000:0xfff0 + +For example, assume the BIOS Directory Table indicates + + destination = 0x9b00000 + size = 0x300000 + +… then the BIOS image is placed at the topmost position the region +0x9b00000-0x9dfffff and + + reset_vector = 0x9dffff0 + CS_shdw_base = 0x9df0000 + CS:IP = 0xf000:0xfff0 + +Although the x86 behaves as though it began executing at 0xfffffff0 +i.e. 0xf000:0xfff0, the initial GDT load must use the physical address +of the table and not the typical CS-centric address. And, the first +jump to protected mode must jump to the physical address in DRAM. Any +code that is position-dependent must be linked to run at the final +destination. + +## Initial coreboot Implementation + +Supporting Picasso doesn’t fit well with many of the coreboot +assumptions. Initial porting shall attempt to fit within existing +coreboot paradigms and make minimal changes to common code. + +### CAR and bootblock + +The coreboot bootblock contains features Picasso doesn’t require or +can’t use, and is assumed to execute in an unusable location. +Picasso’s requirement for bootblock in coreboot will be eliminated. + +### Hybrid romstage + +Picasso’s x86 reset state doesn’t meet the coreboot expectations +for jumping directly to ramstage. The primary feature of romstage is +also not needed, however there are other important features that are +typically in romstage that Picasso does need. + +The romstage architecture is designed around the presence of CAR. +Several features implement ROMSTAGE_CBMEM_INIT_HOOK, expecting to move +data from CAR to cbmem. The hybrid romstage consumes DRAM for the +purpose of implementing the expected CAR storage. This region as well +as the DRAM where romstage is decompressed must be reserved and +unavailable to the OS. + +The initial Picasso port implements a hybrid romstage that contains the +first instruction fetched at the reset vector. It minimally configures +flat protected mode, initializes cbmem, then loads the next stage. +Future work will consider breaking the dependencies mentioned above +and/or potentially loading ramstage directly from the PSP. + +## AGESA v9 on Picasso + +Due to the current inability to publish AGESA source, a pre-built +binary solution remains a requirement. The rewrite from v5 to v9 for +direct inclusion into UEFI source makes modifying it for conforming to +the existing v5 interface impractical. + +Given the UEFI nature of modern AGESA, and the existing open source +work from Intel, Picasso shall support AGESA via an FSP-like prebuilt +image. The Intel Firmware Support Package<sup>4</sup> combines +reference code with EDK II source to create a modular image with +discoverable entry points. coreboot source already contains knowledge +of FSP, how to parse it, integrate it, and how to communicate with it. + +## Footnotes + +1. “AMD Platform Security Processor BIOS Architecture Design Guide +for AMD Family 17h Processors” (PID #55758) and “AMD Platform +Security Processor BIOS Architecture Design Guide” (PID #54267) for +earlier products +2. [https://www.amd.com/system/files/TechDocs/44065_Arch2008.pdf%5D(https://www....) +3. [https://en.wikichip.org/wiki/amd/cores/picasso%5D(https://en.wikichip.org/wi...) +4. [https://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-s...) + diff --git a/Documentation/soc/amd/index.md b/Documentation/soc/amd/index.md new file mode 100644 index 0000000..7945b48 --- /dev/null +++ b/Documentation/soc/amd/index.md @@ -0,0 +1,8 @@ +# AMD SOC-specific documentation + +This section contains documentation about coreboot on specific AMD SOCs. + +## Technology + +- [Family 17h](family17h.md) + diff --git a/Documentation/soc/index.md b/Documentation/soc/index.md index 04e2b2f..fccddbd 100644 --- a/Documentation/soc/index.md +++ b/Documentation/soc/index.md @@ -4,5 +4,6 @@
## Vendor
+- [AMD](amd/index.md) - [Cavium](cavium/index.md) - [Intel](intel/index.md)
-
Marshall Dawson (Code Review) -
Martin Roth (Code Review)