1RMM-EL3 Communication interface 2******************************* 3 4This document defines the communication interface between RMM and EL3. 5There are two parts in this interface: the boot interface and the runtime 6interface. 7 8The Boot Interface defines the ABI between EL3 and RMM when the CPU enters 9R-EL2 for the first time after boot. The cold boot interface defines the ABI 10for the cold boot path and the warm boot interface defines the same for the 11warm path. 12 13The RMM-EL3 runtime interface defines the ABI for EL3 services which can be 14invoked by RMM as well as the register save-restore convention when handling an 15SMC call from NS. 16 17The below sections discuss these interfaces more in detail. 18 19.. _rmm_el3_ifc_versioning: 20 21RMM-EL3 Interface versioning 22____________________________ 23 24The RMM Boot and Runtime Interface uses a version number to check 25compatibility with the register arguments passed as part of Boot Interface and 26RMM-EL3 runtime interface. 27 28The Boot Manifest, discussed later in section :ref:`rmm_el3_boot_manifest`, 29uses a separate version number but with the same scheme. 30 31The version number is a 32-bit type with the following fields: 32 33.. csv-table:: 34 :header: "Bits", "Value" 35 36 [0:15],``VERSION_MINOR`` 37 [16:30],``VERSION_MAJOR`` 38 [31],RES0 39 40The version numbers are sequentially increased and the rules for updating them 41are explained below: 42 43 - ``VERSION_MAJOR``: This value is increased when changes break 44 compatibility with previous versions. If the changes 45 on the ABI are compatible with the previous one, ``VERSION_MAJOR`` 46 remains unchanged. 47 48 - ``VERSION_MINOR``: This value is increased on any change that is backwards 49 compatible with the previous version. When ``VERSION_MAJOR`` is increased, 50 ``VERSION_MINOR`` must be set to 0. 51 52 - ``RES0``: Bit 31 of the version number is reserved 0 as to maintain 53 consistency with the versioning schemes used in other parts of RMM. 54 55This document specifies the 0.3 version of Boot Interface ABI and RMM-EL3 56services specification and the 0.3 version of the Boot Manifest. 57 58.. _rmm_el3_boot_interface: 59 60RMM Boot Interface 61__________________ 62 63This section deals with the Boot Interface part of the specification. 64 65One of the goals of the Boot Interface is to allow EL3 firmware to pass 66down into RMM certain platform specific information dynamically. This allows 67RMM to be less platform dependent and be more generic across platform 68variations. It also allows RMM to be decoupled from the other boot loader 69images in the boot sequence and remain agnostic of any particular format used 70for configuration files. 71 72The Boot Interface ABI defines a set of register conventions and 73also a memory based manifest file to pass information from EL3 to RMM. The 74Boot Manifest and the associated platform data in it can be dynamically created 75by EL3 and there is no restriction on how the data can be obtained (e.g by DTB, 76hoblist or other). 77 78The register convention and the manifest are versioned separately to manage 79future enhancements and compatibility. 80 81RMM completes the boot by issuing the ``RMM_BOOT_COMPLETE`` SMC (0xC40001CF) 82back to EL3. After the RMM has finished the boot process, it can only be 83entered from EL3 as part of RMI handling. 84 85If RMM returns an error during boot (in any CPU), then RMM must not be entered 86from any CPU. 87 88.. _rmm_cold_boot_interface: 89 90Cold Boot Interface 91~~~~~~~~~~~~~~~~~~~ 92 93During cold boot RMM expects the following register values: 94 95.. csv-table:: 96 :header: "Register", "Value" 97 :widths: 1, 5 98 99 x0,Linear index of this PE. This index starts from 0 and must be less than the maximum number of CPUs to be supported at runtime (see x2). 100 x1,Version for this Boot Interface as defined in :ref:`rmm_el3_ifc_versioning`. 101 x2,Maximum number of CPUs to be supported at runtime. RMM should ensure that it can support this maximum number. 102 x3,Base address for the shared buffer used for communication between EL3 firmware and RMM. This buffer must be of 4KB size (1 page). The Boot Manifest must be present at the base of this shared buffer during cold boot. 103 104During cold boot, EL3 firmware needs to allocate a 4KB page that will be 105passed to RMM in x3. This memory will be used as shared buffer for communication 106between EL3 and RMM. It must be assigned to Realm world and must be mapped with 107Normal memory attributes (IWB-OWB-ISH) at EL3. At boot, this memory will be 108used to populate the Boot Manifest. Since the Boot Manifest can be accessed by 109RMM prior to enabling its MMU, EL3 must ensure that proper cache maintenance 110operations are performed after the Boot Manifest is populated. 111 112EL3 should also ensure that this shared buffer is always available for use by RMM 113during the lifetime of the system and that it can be used for runtime 114communication between RMM and EL3. For example, when RMM invokes attestation 115service commands in EL3, this buffer can be used to exchange data between RMM 116and EL3. It is also allowed for RMM to invoke runtime services provided by EL3 117utilizing this buffer during the boot phase, prior to return back to EL3 via 118RMM_BOOT_COMPLETE SMC. 119 120RMM should map this memory page into its Stage 1 page-tables using Normal 121memory attributes. 122 123During runtime, it is the RMM which initiates any communication with EL3. If that 124communication requires the use of the shared area, it is expected that RMM needs 125to do the necessary concurrency protection to prevent the use of the same buffer 126by other PEs. 127 128The following sequence diagram shows how a generic EL3 Firmware would boot RMM. 129 130.. image:: ../resources/diagrams/rmm_cold_boot_generic.png 131 132Warm Boot Interface 133~~~~~~~~~~~~~~~~~~~ 134 135At warm boot, RMM is already initialized and only some per-CPU initialization 136is still pending. The only argument that is required by RMM at this stage is 137the CPU Id, which will be passed through register x0 whilst x1 to x3 are RES0. 138This is summarized in the following table: 139 140.. csv-table:: 141 :header: "Register", "Value" 142 :widths: 1, 5 143 144 x0,Linear index of this PE. This index starts from 0 and must be less than the maximum number of CPUs to be supported at runtime (see x2). 145 x1 - x3,RES0 146 147Boot error handling and return values 148~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 149 150After boot up and initialization, RMM returns control back to EL3 through a 151``RMM_BOOT_COMPLETE`` SMC call. The only argument of this SMC call will 152be returned in x1 and it will encode a signed integer with the error reason 153as per the following table: 154 155.. csv-table:: 156 :header: "Error code", "Description", "ID" 157 :widths: 2 4 1 158 159 ``E_RMM_BOOT_SUCCESS``,Boot successful,0 160 ``E_RMM_BOOT_ERR_UNKNOWN``,Unknown error,-1 161 ``E_RMM_BOOT_VERSION_NOT_VALID``,Boot Interface version reported by EL3 is not supported by RMM,-2 162 ``E_RMM_BOOT_CPUS_OUT_OF_RANGE``,Number of CPUs reported by EL3 larger than maximum supported by RMM,-3 163 ``E_RMM_BOOT_CPU_ID_OUT_OF_RANGE``,Current CPU Id is higher or equal than the number of CPUs supported by RMM,-4 164 ``E_RMM_BOOT_INVALID_SHARED_BUFFER``,Invalid pointer to shared memory area,-5 165 ``E_RMM_BOOT_MANIFEST_VERSION_NOT_SUPPORTED``,Version reported by the Boot Manifest not supported by RMM,-6 166 ``E_RMM_BOOT_MANIFEST_DATA_ERROR``,Error parsing core Boot Manifest,-7 167 168For any error detected in RMM during cold or warm boot, RMM will return back to 169EL3 using ``RMM_BOOT_COMPLETE`` SMC with an appropriate error code. It is 170expected that EL3 will take necessary action to disable Realm world for further 171entry from NS Host on receiving an error. This will be done across all the PEs 172in the system so as to present a symmetric view to the NS Host. Any further 173warm boot by any PE should not enter RMM using the warm boot interface. 174 175.. _rmm_el3_boot_manifest: 176 177Boot Manifest 178~~~~~~~~~~~~~ 179 180During cold boot, EL3 Firmware passes a memory Boot Manifest to RMM containing 181platform information. 182 183This Boot Manifest is versioned independently of the Boot Interface, to help 184evolve the former independent of the latter. 185The current version for the Boot Manifest is ``v0.3`` and the rules explained 186in :ref:`rmm_el3_ifc_versioning` apply on this version as well. 187 188The Boot Manifest v0.3 has the following fields: 189 190 - version : Version of the Manifest (v0.3) 191 - plat_data : Pointer to the platform specific data and not specified by this 192 document. These data are optional and can be NULL. 193 - plat_dram : Structure encoding the NS DRAM information on the platform. This 194 field is optional and platform can choose to zero out this structure if 195 RMM does not need EL3 to send this information during the boot. 196 - plat_console : Structure encoding the list of consoles for RMM use on the 197 platform. This field is optional and platform can choose to not populate 198 the console list if this is not needed by the RMM for this platform. 199 200For the current version of the Boot Manifest, the core manifest contains a pointer 201to the platform data. EL3 must ensure that the whole Boot Manifest, including 202the platform data, if available, fits inside the RMM EL3 shared buffer. 203 204For the data structure specification of Boot Manifest, refer to 205:ref:`rmm_el3_manifest_struct` 206 207.. _runtime_services_and_interface: 208 209RMM-EL3 Runtime Interface 210__________________________ 211 212This section defines the RMM-EL3 runtime interface which specifies the ABI for 213EL3 services expected by RMM at runtime as well as the register save and 214restore convention between EL3 and RMM as part of RMI call handling. It is 215important to note that RMM is allowed to invoke EL3-RMM runtime interface 216services during the boot phase as well. The EL3 runtime service handling must 217not result in a world switch to another world unless specified. Both the RMM 218and EL3 are allowed to make suitable optimizations based on this assumption. 219 220If the interface requires the use of memory, then the memory references should 221be within the shared buffer communicated as part of the boot interface. See 222:ref:`rmm_cold_boot_interface` for properties of this shared buffer which both 223EL3 and RMM must adhere to. 224 225RMM-EL3 runtime service return codes 226~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 227 228The return codes from EL3 to RMM is a 32 bit signed integer which encapsulates 229error condition as described in the following table: 230 231.. csv-table:: 232 :header: "Error code", "Description", "ID" 233 :widths: 2 4 1 234 235 ``E_RMM_OK``,No errors detected,0 236 ``E_RMM_UNK``,Unknown/Generic error,-1 237 ``E_RMM_BAD_ADDR``,The value of an address used as argument was invalid,-2 238 ``E_RMM_BAD_PAS``,Incorrect PAS,-3 239 ``E_RMM_NOMEM``,Not enough memory to perform an operation,-4 240 ``E_RMM_INVAL``,The value of an argument was invalid,-5 241 ``E_RMM_AGAIN``,The resource is busy. Try again.,-6 242 243If multiple failure conditions are detected in an RMM to EL3 command, then EL3 244is allowed to return an error code corresponding to any of the failure 245conditions. 246 247RMM-EL3 runtime services 248~~~~~~~~~~~~~~~~~~~~~~~~ 249 250The following table summarizes the RMM runtime services that need to be 251implemented by EL3 Firmware. 252 253.. csv-table:: 254 :header: "FID", "Command" 255 :widths: 2 5 256 257 0xC400018F,``RMM_RMI_REQ_COMPLETE`` 258 0xC40001B0,``RMM_GTSI_DELEGATE`` 259 0xC40001B1,``RMM_GTSI_UNDELEGATE`` 260 0xC40001B2,``RMM_ATTEST_GET_REALM_KEY`` 261 0xC40001B3,``RMM_ATTEST_GET_PLAT_TOKEN`` 262 263RMM_RMI_REQ_COMPLETE command 264============================ 265 266Notifies the completion of an RMI call to the Non-Secure world. 267 268This call is the only function currently in RMM-EL3 runtime interface which 269results in a world switch to NS. This call is the reply to the original RMI 270call and it is forwarded by EL3 to the NS world. 271 272FID 273--- 274 275``0xC400018F`` 276 277Input values 278------------ 279 280.. csv-table:: 281 :header: "Name", "Register", "Field", "Type", "Description" 282 :widths: 1 1 1 1 5 283 284 fid,x0,[63:0],UInt64,Command FID 285 err_code,x1,[63:0],RmiCommandReturnCode,Error code returned by the RMI service invoked by NS World. See Realm Management Monitor specification for more info 286 287Output values 288------------- 289 290This call does not return. 291 292Failure conditions 293------------------ 294 295Since this call does not return to RMM, there is no failure condition which 296can be notified back to RMM. 297 298RMM_GTSI_DELEGATE command 299========================= 300 301Delegate a memory granule by changing its PAS from Non-Secure to Realm. 302 303FID 304--- 305 306``0xC40001B0`` 307 308Input values 309------------ 310 311.. csv-table:: 312 :header: "Name", "Register", "Field", "Type", "Description" 313 :widths: 1 1 1 1 5 314 315 fid,x0,[63:0],UInt64,Command FID 316 base_pa,x1,[63:0],Address,PA of the start of the granule to be delegated 317 318Output values 319------------- 320 321.. csv-table:: 322 :header: "Name", "Register", "Field", "Type", "Description" 323 :widths: 1 1 1 2 4 324 325 Result,x0,[63:0],Error Code,Command return status 326 327Failure conditions 328------------------ 329 330The table below shows all the possible error codes returned in ``Result`` upon 331a failure. The errors are ordered by condition check. 332 333.. csv-table:: 334 :header: "ID", "Condition" 335 :widths: 1 5 336 337 ``E_RMM_BAD_ADDR``,``PA`` does not correspond to a valid granule address 338 ``E_RMM_BAD_PAS``,The granule pointed by ``PA`` does not belong to Non-Secure PAS 339 ``E_RMM_OK``,No errors detected 340 341RMM_GTSI_UNDELEGATE command 342=========================== 343 344Undelegate a memory granule by changing its PAS from Realm to Non-Secure. 345 346FID 347--- 348 349``0xC40001B1`` 350 351Input values 352------------ 353 354.. csv-table:: 355 :header: "Name", "Register", "Field", "Type", "Description" 356 :widths: 1 1 1 1 5 357 358 fid,x0,[63:0],UInt64,Command FID 359 base_pa,x1,[63:0],Address,PA of the start of the granule to be undelegated 360 361Output values 362------------- 363 364.. csv-table:: 365 :header: "Name", "Register", "Field", "Type", "Description" 366 :widths: 1 1 1 2 4 367 368 Result,x0,[63:0],Error Code,Command return status 369 370Failure conditions 371------------------ 372 373The table below shows all the possible error codes returned in ``Result`` upon 374a failure. The errors are ordered by condition check. 375 376.. csv-table:: 377 :header: "ID", "Condition" 378 :widths: 1 5 379 380 ``E_RMM_BAD_ADDR``,``PA`` does not correspond to a valid granule address 381 ``E_RMM_BAD_PAS``,The granule pointed by ``PA`` does not belong to Realm PAS 382 ``E_RMM_OK``,No errors detected 383 384RMM_ATTEST_GET_REALM_KEY command 385================================ 386 387Retrieve the Realm Attestation Token Signing key from EL3. 388 389FID 390--- 391 392``0xC40001B2`` 393 394Input values 395------------ 396 397.. csv-table:: 398 :header: "Name", "Register", "Field", "Type", "Description" 399 :widths: 1 1 1 1 5 400 401 fid,x0,[63:0],UInt64,Command FID 402 buf_pa,x1,[63:0],Address,PA where the Realm Attestation Key must be stored by EL3. The PA must belong to the shared buffer 403 buf_size,x2,[63:0],Size,Size in bytes of the Realm Attestation Key buffer. ``bufPa + bufSize`` must lie within the shared buffer 404 ecc_curve,x3,[63:0],Enum,Type of the elliptic curve to which the requested attestation key belongs to. See :ref:`ecc_curves` 405 406Output values 407------------- 408 409.. csv-table:: 410 :header: "Name", "Register", "Field", "Type", "Description" 411 :widths: 1 1 1 1 5 412 413 Result,x0,[63:0],Error Code,Command return status 414 keySize,x1,[63:0],Size,Size of the Realm Attestation Key 415 416Failure conditions 417------------------ 418 419The table below shows all the possible error codes returned in ``Result`` upon 420a failure. The errors are ordered by condition check. 421 422.. csv-table:: 423 :header: "ID", "Condition" 424 :widths: 1 5 425 426 ``E_RMM_BAD_ADDR``,``PA`` is outside the shared buffer 427 ``E_RMM_INVAL``,``PA + BSize`` is outside the shared buffer 428 ``E_RMM_INVAL``,``Curve`` is not one of the listed in :ref:`ecc_curves` 429 ``E_RMM_UNK``,An unknown error occurred whilst processing the command 430 ``E_RMM_OK``,No errors detected 431 432.. _ecc_curves: 433 434Supported ECC Curves 435-------------------- 436 437.. csv-table:: 438 :header: "ID", "Curve" 439 :widths: 1 5 440 441 0,ECC SECP384R1 442 443RMM_ATTEST_GET_PLAT_TOKEN command 444================================= 445 446Retrieve the Platform Token from EL3. If the entire token does not fit in the 447buffer, EL3 returns a hunk of the token (via ``tokenHunkSize`` parameter) and 448indicates the remaining bytes that are pending retrieval (via ``remainingSize`` 449parameter). The challenge object for the platform token must be populated in 450the buffer for the first call of this command and the size of the object is 451indicated by ``c_size`` parameter. Subsequent calls to retrieve remaining hunks of 452the token must be made with ``c_size`` as 0. 453 454If ``c_size`` is not 0, this command could cause regeneration of platform token 455and will return token hunk corresponding to beginning of the token. 456 457It is valid for the calls of this command to return ``E_RMM_AGAIN`` error, 458which is an indication to the caller to retry this command again. Depending on the 459platform, this mechanism can be used to implement queuing to HES, if HES is 460involved in platform token generation. 461 462FID 463--- 464 465``0xC40001B3`` 466 467Input values 468------------ 469 470.. csv-table:: 471 :header: "Name", "Register", "Field", "Type", "Description" 472 :widths: 1 1 1 1 5 473 474 fid,x0,[63:0],UInt64,Command FID 475 buf_pa,x1,[63:0],Address,"PA of the platform attestation token. The challenge object must be passed in this buffer for the first call of this command. Any subsequent calls, if required to retrieve the full token, should not have this object. The PA must belong to the shared buffer." 476 buf_size,x2,[63:0],Size,Size in bytes of the platform attestation token buffer. ``bufPa + bufSize`` must lie within the shared buffer 477 c_size,x3,[63:0],Size,"Size in bytes of the challenge object. It corresponds to the size of one of the defined SHA algorithms. Any subsequent calls, if required to retrieve the full token, should set this size to 0." 478 479Output values 480------------- 481 482.. csv-table:: 483 :header: "Name", "Register", "Field", "Type", "Description" 484 :widths: 1 1 1 1 5 485 486 Result,x0,[63:0],Error Code,Command return status 487 tokenHunkSize,x1,[63:0],Size,Size of the platform token hunk retrieved 488 remainingSize,x2,[63:0],Size,Remaining bytes of the token that are pending retrieval 489 490Failure conditions 491------------------ 492 493The table below shows all the possible error codes returned in ``Result`` upon 494a failure. The errors are ordered by condition check. 495 496.. csv-table:: 497 :header: "ID", "Condition" 498 :widths: 1 5 499 500 ``E_RMM_AGAIN``,Resource for Platform token retrieval is busy. Try again. 501 ``E_RMM_BAD_ADDR``,``PA`` is outside the shared buffer 502 ``E_RMM_INVAL``,``PA + BSize`` is outside the shared buffer 503 ``E_RMM_INVAL``,``CSize`` does not represent the size of a supported SHA algorithm for the first call to this command 504 ``E_RMM_INVAL``,``CSize`` is not 0 for subsequent calls to retrieve remaining hunks of the token 505 ``E_RMM_UNK``,An unknown error occurred whilst processing the command 506 ``E_RMM_OK``,No errors detected 507 508RMM-EL3 world switch register save restore convention 509_____________________________________________________ 510 511As part of NS world switch, EL3 is expected to maintain a register context 512specific to each world and will save and restore the registers 513appropriately. This section captures the contract between EL3 and RMM on the 514register set to be saved and restored. 515 516EL3 must maintain a separate register context for the following: 517 518 #. General purpose registers (x0-x30) and ``sp_el0``, ``sp_el2`` stack pointers 519 #. EL2 system register context for all enabled features by EL3. These include system registers with the ``_EL2`` prefix. The EL2 physical and virtual timer registers must not be included in this. 520 521As part of SMC forwarding between the NS world and Realm world, EL3 allows x0-x7 to be passed 522as arguments to Realm and x0-x4 to be used for return arguments back to Non Secure. 523As per SMCCCv1.2, x4 must be preserved if not being used as return argument by the SMC function 524and it is the responsibility of RMM to preserve this or use this as a return argument. 525EL3 will always copy x0-x4 from Realm context to NS Context. 526 527EL3 must save and restore the following as part of world switch: 528 #. EL2 system registers with the exception of ``zcr_el2`` register. 529 #. PAuth key registers (APIA, APIB, APDA, APDB, APGA). 530 531EL3 will not save some registers as mentioned in the below list. It is the 532responsibility of RMM to ensure that these are appropriately saved if the 533Realm World makes use of them: 534 535 #. FP/SIMD registers 536 #. SVE registers 537 #. SME registers 538 #. EL1/0 registers with the exception of PAuth key registers as mentioned above. 539 #. zcr_el2 register. 540 541It is essential that EL3 honors this contract to maintain the Confidentiality and integrity 542of the Realm world. 543 544SMCCC v1.3 allows NS world to specify whether SVE context is in use. In this 545case, RMM could choose to not save the incoming SVE context but must ensure 546to clear SVE registers if they have been used in Realm World. The same applies 547to SME registers. 548 549Types 550_____ 551 552.. _rmm_el3_manifest_struct: 553 554RMM-EL3 Boot Manifest structure 555~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 556 557The RMM-EL3 Boot Manifest v0.3 structure contains platform boot information passed 558from EL3 to RMM. The size of the Boot Manifest is 64 bytes. 559 560The members of the RMM-EL3 Boot Manifest structure are shown in the following 561table: 562 563+--------------+--------+----------------+----------------------------------------+ 564| Name | Offset | Type | Description | 565+==============+========+================+========================================+ 566| version | 0 | uint32_t | Boot Manifest version | 567+--------------+--------+----------------+----------------------------------------+ 568| padding | 4 | uint32_t | Reserved, set to 0 | 569+--------------+--------+----------------+----------------------------------------+ 570| plat_data | 8 | uintptr_t | Pointer to Platform Data section | 571+--------------+--------+----------------+----------------------------------------+ 572| plat_dram | 16 | ns_dram_info | NS DRAM Layout Info structure | 573+--------------+--------+----------------+----------------------------------------+ 574| plat_console | 40 | console_list | List of consoles available to RMM | 575+--------------+--------+----------------+----------------------------------------+ 576 577.. _ns_dram_info_struct: 578 579NS DRAM Layout Info structure 580~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 581 582NS DRAM Layout Info structure contains information about platform Non-secure 583DRAM layout. The members of this structure are shown in the table below: 584 585+-----------+--------+----------------+----------------------------------------+ 586| Name | Offset | Type | Description | 587+===========+========+================+========================================+ 588| num_banks | 0 | uint64_t | Number of NS DRAM banks | 589+-----------+--------+----------------+----------------------------------------+ 590| banks | 8 | ns_dram_bank * | Pointer to 'ns_dram_bank'[] array | 591+-----------+--------+----------------+----------------------------------------+ 592| checksum | 16 | uint64_t | Checksum | 593+-----------+--------+----------------+----------------------------------------+ 594 595Checksum is calculated as two's complement sum of 'num_banks', 'banks' pointer 596and DRAM banks data array pointed by it. 597 598.. _ns_dram_bank_struct: 599 600NS DRAM Bank structure 601~~~~~~~~~~~~~~~~~~~~~~ 602 603NS DRAM Bank structure contains information about each Non-secure DRAM bank: 604 605+-----------+--------+----------------+----------------------------------------+ 606| Name | Offset | Type | Description | 607+===========+========+================+========================================+ 608| base | 0 | uintptr_t | Base address | 609+-----------+--------+----------------+----------------------------------------+ 610| size | 8 | uint64_t | Size of bank in bytes | 611+-----------+--------+----------------+----------------------------------------+ 612 613.. _console_list_struct: 614 615Console List structure 616~~~~~~~~~~~~~~~~~~~~~~ 617 618Console List structure contains information about the available consoles for RMM. 619The members of this structure are shown in the table below: 620 621+--------------+--------+----------------+----------------------------------------+ 622| Name | Offset | Type | Description | 623+==============+========+================+========================================+ 624| num_consoles | 0 | uint64_t | Number of consoles | 625+--------------+--------+----------------+----------------------------------------+ 626| consoles | 8 | console_info * | Pointer to 'console_info'[] array | 627+--------------+--------+----------------+----------------------------------------+ 628| checksum | 16 | uint64_t | Checksum | 629+--------------+--------+----------------+----------------------------------------+ 630 631Checksum is calculated as two's complement sum of 'num_consoles', 'consoles' 632pointer and the consoles array pointed by it. 633 634.. _console_info_struct: 635 636Console Info structure 637~~~~~~~~~~~~~~~~~~~~~~ 638 639Console Info structure contains information about each Console available to RMM. 640 641+-----------+--------+---------------+----------------------------------------+ 642| Name | Offset | Type | Description | 643+===========+========+===============+========================================+ 644| base | 0 | uintptr_t | Console Base address | 645+-----------+--------+---------------+----------------------------------------+ 646| map_pages | 8 | uint64_t | Num of pages to map for console MMIO | 647+-----------+--------+---------------+----------------------------------------+ 648| name | 16 | char[] | Name of console | 649+-----------+--------+---------------+----------------------------------------+ 650| clk_in_hz | 24 | uint64_t | UART clock (in hz) for console | 651+-----------+--------+---------------+----------------------------------------+ 652| baud_rate | 32 | uint64_t | Baud rate | 653+-----------+--------+---------------+----------------------------------------+ 654| flags | 40 | uint64_t | Additional flags (RES0) | 655+-----------+--------+---------------+----------------------------------------+ 656 657
