TOR Magic header support

HW-Image-Coreq=Yes
SBE-Image-Coreq=No (SBE image is back compatible)

This commit adds an 12-byte header to all TOR ring sections:
- for improved self-containment of TOR ring sections incl
  stand-alone ring sections like .overrides which, currently,
  has no meaningful size info associated with it in the PNOR,
- to support a more data-driven implementation of TOR API,
- to eliminate the current usage of XIP_MAGIC ids to inform the
  TOR APIs which ring section they are dealing with, and
- to improve debugging binary ring sections.

The TOR header expands on the current TorNumDdLevels field in the
HW ring section and is added to all other ring sections as well,
e.g. for the SBE and OVRD ring sections.  Most importantly, the
TOR header adds the TOR magic number which is unique for each
possible TOR ring section. Also, of quite practical importance,
a size field has been added so that the size of a true standalone
section like .overrides can be extracted (since its size in PNOR
is not indicative of its size).

Further, to support the use of ddLevel and chipType in the TOR
header fields, these two data points need to be always supplied
whenever calling ring_apply. Thus, updates have been made to the
ring_apply.mk file as well as the override .pl script.  While
making these changes, we also decided to change the --type arg
to the --bOverrides arg to make the arguments being passed less
confusing in view of the Centaur commit that's coming and its
demands to make codes less data dependent, incl make and script
files which should simply inform the functional intent of the
"user". The user shouldn't presume it knows about which specific
type of ring section needs to be produced.

Further, the DD level block struct has been increased from 8B
to 12B to avoid the unnecessarily complex merging of the
ddLevel and offset into the same 4B field. It's included in
this commit since this is also going to break the lab and
because the required code changes are in the same places
where the code changes needed for the TOR header are.

Further, xip_tool has been updated to support the new TOR
header so that it can be called by supplying a standalone
ring section, such as overrides.bin. Various changes have
been made in xip_tool's dissect section to support overrides
as well.

This code uses many  of the code changes in 33778 except
changes to p9_tor.C|H are at a bare minimum focusing on the
functional changes and keeping any cleanups to a minimum changing
only some variable names associated with the functional changes
for improved readability of the code.

CMVC-Prereq: 1034144
CMVC-Prereq: 1035575
Change-Id: I29ba8905ac55dad5c10878a94fb94468e5580ea0
Reviewed-on: http://ralgit01.raleigh.ibm.com/gerrit1/35372
Tested-by: Jenkins Server <pfd-jenkins+hostboot@us.ibm.com>
Tested-by: HWSV CI <hwsv-ci+hostboot@us.ibm.com>
Reviewed-by: Jennifer A. Stofer <stofer@us.ibm.com>
Reviewed-on: http://ralgit01.raleigh.ibm.com/gerrit1/37993
Reviewed-by: Hostboot Team <hostboot@us.ibm.com>
Tested-by: FSP CI Jenkins <fsp-CI-jenkins+hostboot@us.ibm.com>
Reviewed-by: Sachin Gupta <sgupta2m@in.ibm.com>

1 files changed, 20 insertions, 3 deletions

diff --git a/src/import/chips/p9/utils/imageProcs/p9_ringId.H b/src/import/chips/p9/utils/imageProcs/p9_ringId.H
index bd89194d..8c8fbdcf 100644
--- a/src/import/chips/p9/utils/imageProcs/p9_ringId.H
+++ b/src/import/chips/p9/utils/imageProcs/p9_ringId.H
@@ -68,9 +68,10 @@ typedef enum RingVariant   // Base variables
     NOT_VALID = 0xff
 } RingVariant_t;
 
+#define P9_RINGID_VARIANT_ORDER_SIZE 3
 typedef struct
 {
-    uint8_t  variant[3];
+    uint8_t  variant[P9_RINGID_VARIANT_ORDER_SIZE];
 } RingVariantOrder;
 
 
@@ -244,6 +245,7 @@ const uint8_t INSTANCE_RING_MASK = 0x7F;
 
 namespace PERV
 {
+// FIXME: this struct is nonsense - no one uses these fields (we only need the variant number)
 struct RingVariants
 {
     uint16_t iv_base;
@@ -289,6 +291,7 @@ static const CHIPLET_DATA g_pervData =
 
 namespace N0
 {
+// FIXME: this struct is nonsense - no one uses these fields (we only need the variant number)
 struct RingVariants
 {
     uint16_t iv_base;
@@ -318,12 +321,13 @@ static const CHIPLET_DATA g_n0Data =
     2, // N0 Chiplet ID is 2.
     9, // 9 common rings for N0 Chiplet
     3, // 3 instance specific rings for N0 chiplet
-    3
+    3  // FIXME: number of variants? doesn't match RingVariants below!
 };
 };
 
 namespace N1
 {
+// FIXME: this struct is nonsense - no one uses these fields (we only need the variant number)
 struct RingVariants
 {
     uint16_t iv_base;
@@ -363,6 +367,7 @@ static const CHIPLET_DATA g_n1Data =
 
 namespace N2
 {
+// FIXME: this struct is nonsense - no one uses these fields (we only need the variant number)
 struct RingVariants
 {
     uint16_t iv_base;
@@ -398,6 +403,7 @@ static const CHIPLET_DATA g_n2Data =
 
 namespace N3
 {
+// FIXME: this struct is nonsense - no one uses these fields (we only need the variant number)
 struct RingVariants
 {
     uint16_t iv_base;
@@ -434,6 +440,7 @@ static const CHIPLET_DATA g_n3Data =
 
 namespace XB
 {
+// FIXME: this struct is nonsense - no one uses these fields (we only need the variant number)
 struct RingVariants
 {
     uint16_t iv_base;
@@ -476,6 +483,7 @@ static const CHIPLET_DATA g_xbData =
 
 namespace MC
 {
+// FIXME: this struct is nonsense - no one uses these fields (we only need the variant number)
 struct RingVariants
 {
     uint16_t iv_base;
@@ -519,6 +527,7 @@ static const CHIPLET_DATA g_mcData =
 
 namespace OB0
 {
+// FIXME: this struct is nonsense - no one uses these fields (we only need the variant number)
 struct RingVariants
 {
     uint16_t iv_base;
@@ -551,6 +560,7 @@ static const CHIPLET_DATA g_ob0Data =
 
 namespace OB1
 {
+// FIXME: this struct is nonsense - no one uses these fields (we only need the variant number)
 struct RingVariants
 {
     uint16_t iv_base;
@@ -584,6 +594,7 @@ static const CHIPLET_DATA g_ob1Data =
 
 namespace OB2
 {
+// FIXME: this struct is nonsense - no one uses these fields (we only need the variant number)
 struct RingVariants
 {
     uint16_t iv_base;
@@ -616,6 +627,7 @@ static const CHIPLET_DATA g_ob2Data =
 
 namespace OB3
 {
+// FIXME: this struct is nonsense - no one uses these fields (we only need the variant number)
 struct RingVariants
 {
     uint16_t iv_base;
@@ -647,6 +659,7 @@ static const CHIPLET_DATA g_ob3Data =
 }; // end of namespace OB2
 namespace PCI0
 {
+// FIXME: this struct is nonsense - no one uses these fields (we only need the variant number)
 struct RingVariants
 {
     uint16_t iv_base;
@@ -676,6 +689,7 @@ static const CHIPLET_DATA g_pci0Data =
 
 namespace PCI1
 {
+// FIXME: this struct is nonsense - no one uses these fields (we only need the variant number)
 struct RingVariants
 {
     uint16_t iv_base;
@@ -705,6 +719,7 @@ static const CHIPLET_DATA g_pci1Data =
 
 namespace PCI2
 {
+// FIXME: this struct is nonsense - no one uses these fields (we only need the variant number)
 struct RingVariants
 {
     uint16_t iv_base;
@@ -735,6 +750,7 @@ static const CHIPLET_DATA g_pci2Data =
 
 namespace EQ
 {
+// FIXME: this struct is nonsense - no one uses these fields (we only need the variant number)
 struct RingVariants
 {
     uint16_t iv_base;
@@ -832,6 +848,7 @@ static const CHIPLET_DATA g_eqData =
 
 namespace EC
 {
+// FIXME: this struct is nonsense - no one uses these fields (we only need the variant number)
 struct RingVariants
 {
     uint16_t iv_base;
@@ -868,7 +885,7 @@ static const uint8_t INVALID_RING = 0xFF;
 #ifndef __PPE__
 struct ringProperties_t
 {
-    uint8_t iv_torOffSet;
+    uint8_t iv_torOffSet;  // FIXME: misnomer
     char iv_name[50];
     CHIPLET_TYPE iv_type;
 };