[processor-sdk/pdk.git] / packages / ti / drv / sciclient / soc / sysfw / binaries / system-firmware-public-documentation / _sources / 2_tisci_msgs / security / PROC_BOOT.rst.txt
1 ===========================================
2 Processor Boot Management TISCI Description
3 ===========================================
5 Introduction
6 ============
8 This chapter provides information about the messaging APIs for the processor
9 boot control. APIs are divided into the following two sets:
11 - Book keeping APIs - Meant to control access to allow a reasonable usage
12 scenario of processors.
13 - Processor Control APIs - Meant to be the actual Processor Core controls.
15 Book Keeping APIs:
17 +------------------+----------------------------------------------------------------+
18 | TISCI Message ID | Message Name |
19 +==================+================================================================+
20 | 0xC000 | :ref:`TISCI_MSG_PROC_REQUEST <proc-boot-request-processor>`. |
21 +------------------+----------------------------------------------------------------+
22 | 0xC001 | :ref:`TISCI_MSG_PROC_RELEASE <proc-boot-release-processor>`. |
23 +------------------+----------------------------------------------------------------+
24 | 0xC005 | :ref:`TISCI_MSG_PROC_HANDOVER <proc-boot-handover-processor>`. |
25 +------------------+----------------------------------------------------------------+
27 Processor Control APIs:
29 +------------------+----------------------------------------------------------------------------------------+
30 | TISCI Message ID | Message Name |
31 +==================+========================================================================================+
32 | 0xC100 | :ref:`TISCI_MSG_PROC_SET_CONFIG <proc-boot-set-processor-configuration>` |
33 +------------------+----------------------------------------------------------------------------------------+
34 | 0xC101 | :ref:`TISCI_MSG_PROC_SET_CONTROL <proc-boot-set-processor-control>` |
35 +------------------+----------------------------------------------------------------------------------------+
36 | 0xC120 | :ref:`TISCI_MSG_PROC_AUTH_BOOT <proc-boot-authenticate-image-and-configure-processor>` |
37 +------------------+----------------------------------------------------------------------------------------+
38 | 0xC400 | :ref:`TISCI_MSG_PROC_GET_STATUS <proc_boot_get_processor_status>` |
39 +------------------+----------------------------------------------------------------------------------------+
40 | 0xC401 | :ref:`TISCI_MSG_PROC_WAIT_STATUS <proc_boot_wait_processor_status>` |
41 +------------------+----------------------------------------------------------------------------------------+
43 The APIs use the overall concepts explained in the following sections.
45 ID definition
46 -------------
48 To help identify the various entities invovled, the following IDs are involved:
50 - HOST_ID is the concept of identifying processing entities (SoC specific)
51 - PROC_ID is the specific hardware processor instance involved (SoC specific)
53 Access control definition
54 -------------------------
56 Access control is enforced via the Book keeping APIs. The basic definition of access is as follows:
58 * We identify a requester (just like rest of TISCI) using Host ID (or plain Host).
59 * By default, we permit all processors to be controlled by any other Host (no policing).
60 * Board configuration provides: per PROC_ID, a limited list of "permitted host IDs"
61 which are permitted to control a processor. BUT with the following conditions:
63 * Only one host can control a processor at a time
64 * A host(with control) can hand over control of a processor to another host
65 in the permitted list.
66 * "recovery master" host id is identified in board cfg and this host can
67 override the ownership already established.
69 In addition, ONLY a secure host can request for an authenticated image access.
71 API access control will be as follows:
73 - request_processor: Only one host can get control from access list. However,
74 "recovery master" host can override previously allocated master.
75 - handover_processor: Only the host with current control of the processor.
76 - release_processor: Only the host with current control of the processor.
77 - set_processor_config: Only the host with current control of the processor.
78 - get_processor_config: Any host within the access control list.
79 - set_processor_control: Only the host with current control of the processor.
80 - get_processor_control: Any host within the access control list.
81 - authenticate_and_start_image: Only a *secure* host with current
82 control of the processor.
83 - set_processor_suspend_ready: Only the host with current control of
84 processor can report that the processor is ready to suspend
85 - get_processor_wake_reason: Any host within the access control list.
87 Sequencing of APIs
88 ------------------
90 The boot APIs must be used in correct sequence with the device and clock APIs to
91 be operational. This sequence would be specific to the processor involved.
93 Rationale: by encoding the sequence of processor boot along with boot
94 configuration API will complicate management of processors, since the
95 operational requirements are extremely varied. Some processors need the boot
96 configuration done, clocked, and specific MMU/RAT configuration be done prior to
97 be released from reset. Many of the operations may require interaction with
98 specific processor internals that is hard to make generic and usecase
99 independent.
101 Example usage of APIs
102 ---------------------
104 Example 1: Boot a processor from one core and let it self manage:
106 #. Boot host: (optionally) PM apis to control clock and hold processor in
107 reset. This might be necessary for some processors to get the boot
108 vector registers to be accessible in the first place.
109 #. Boot host: request_processor
110 #. Boot host: set_processor_config -> set bootvector
111 #. Alternatively call authenticate and start image API.
112 #. Boot host: handover_processor -> give control to 'processor host'
113 #. Boot host: PM apis to control clock and release processor from reset.
114 'processor host' gets active. It is probably better to release the processor
115 from reset after handover, in case the 'processor host' tries to do
116 additional operations. however this depends on usecase - use a sane
117 judgement as to how to sequence the APIs.
118 #. Processor host: (continues to boot and do other TISCI APIs permitted)
119 #. Processor host: set_processor_suspend_ready -> ready to suspend
120 #. Processor WFI Wakeup:
121 #. Processor host: get_processor_wake_reason -> get reason for wakeup.
122 .... until all operations are complete...
123 #. Processor host: set_processor_suspend_ready -> state it is going down
124 #. Processor host: release_processor -> Mark no longer required
125 #. Processor WFI (NOTE: a processor cannot switch off it's own clocks -> so
126 in case of a self managed processor shutdown sequence, it will need
127 System firmware to help do the last stages of operation - typically
128 this will involve either shutdown OR reset sequence).
130 Example 2: Boot a processor from one core and recover from another core:
132 #. Boot host: request_processor
133 #. Boot host: set_processor_config -> set bootvector
134 #. Boot host: handover_processor -> give control to 'processor host'
135 #. Boot host: PM apis to control clock and release processor boot host dies
136 #. Recovery Host: request_processor
137 #. Recovery Host: set_processor_config -> force power off
138 #. Recovery Host: PM apis to control clock and force power off of processor
139 #. Recovery Host: Additional cleanup API calls .... Restoration sequence....
141 Processor Boot API Description
142 ==============================
144 This Section goes into details on the various APIs involved for processor control
146 .. note::
147 Reference :ref:`pub_soc_family_doc` to see Host IDs and Processor IDs for
148 your SoC.
150 Book Keeping APIs
151 -----------------
153 These are the top level APIs that provide access control knobs for
154 :ref:`processor operation APIs <proc-boot-processor-control-apis>` to be valid.
156 .. _proc-boot-request-processor:
158 TISCI_MSG_PROC_REQUEST - Request Processor
159 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
161 **Usage**:
163 +------------------------+--------+
164 | **Message Type** | Normal |
165 +------------------------+--------+
166 | **Secure Queue Only?** | No |
167 +------------------------+--------+
169 **TISCI Message ID**
171 .. sysfwapimacro:: TISCI_MSG_PROC_REQUEST
173 .. sysfwapistruct:: tisci_msg_proc_request_req
175 .. sysfwapistruct:: tisci_msg_proc_request_resp
177 .. _proc-boot-release-processor:
179 TISCI_MSG_PROC_RELEASE - Release Processor
180 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
182 **Usage**:
184 +------------------------+--------+
185 | **Message Type** | Normal |
186 +------------------------+--------+
187 | **Secure Queue Only?** | No |
188 +------------------------+--------+
190 **TISCI Message ID**
192 .. sysfwapimacro:: TISCI_MSG_PROC_RELEASE
194 .. sysfwapistruct:: tisci_msg_proc_release_req
196 .. sysfwapistruct:: tisci_msg_proc_release_resp
198 .. _proc-boot-handover-processor:
200 TISCI_MSG_PROC_HANDOVER - Handover Processor
201 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
203 **Usage**:
205 +------------------------+--------+
206 | **Message Type** | Normal |
207 +------------------------+--------+
208 | **Secure Queue Only?** | No |
209 +------------------------+--------+
211 **TISCI Message ID**
213 .. sysfwapimacro:: TISCI_MSG_PROC_HANDOVER
215 .. sysfwapistruct:: tisci_msg_proc_handover_req
217 .. sysfwapistruct:: tisci_msg_proc_handover_resp
219 .. _proc-boot-processor-control-apis:
221 Processor Control APIs
222 ----------------------
224 These are granular control APIs for control of the processor state themselves.
225 These APIs need to be used in conjunction with standard Power Management APIs.
227 .. note::
228 Not all APIs are supported for all processors. See :ref:`Processor Specific Flags <proc_boot_flags>`
229 for core specific flags (implies the applicable APIs are valid for that type of
230 core).
232 .. _proc-boot-set-processor-configuration:
234 TISCI_MSG_PROC_SET_CONFIG - Set Processor Configuration
235 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
237 **Purpose**: Provides a means for the host with current control to do the base
238 configuration of the processor.
240 **Usage**:
242 +------------------------+--------+
243 | **Message Type** | Normal |
244 +------------------------+--------+
245 | **Secure Queue Only?** | No |
246 +------------------------+--------+
248 **TISCI Message ID**
250 .. sysfwapimacro:: TISCI_MSG_PROC_SET_CONFIG
252 .. sysfwapistruct:: tisci_msg_proc_set_config_req
254 .. note::
255 Boot vector address and config are processor specific configurations. This
256 may be done in separate invocations as required in processor specific startup
257 sequence.
259 .. sysfwapistruct:: tisci_msg_proc_set_config_resp
261 .. attention::
262 Reason for failure is NOT provided to prevent security attacks by
263 scan. If permitted, System firmware logs shall provide relevant failure
264 information.
266 .. _proc-boot-set-processor-control:
268 TISCI_MSG_PROC_SET_CONTROL - Set Processor Control Flags
269 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
271 **Purpose**: Provides a means for the host with current control to setup limited
272 control flags in specific cases.
274 **Usage**:
276 +------------------------+--------+
277 | **Message Type** | Normal |
278 +------------------------+--------+
279 | **Secure Queue Only?** | No |
280 +------------------------+--------+
282 **TISCI Message ID**
284 .. sysfwapimacro:: TISCI_MSG_PROC_SET_CONTROL
286 .. sysfwapistruct:: tisci_msg_proc_set_control_req
288 .. sysfwapistruct:: tisci_msg_proc_set_control_resp
290 .. attention::
291 Reason for failure is NOT provided to prevent security attacks by
292 scan. If permitted, System firmware logs shall provide relevant failure
293 information.
295 .. _proc-boot-authenticate-image-and-configure-processor:
297 TISCI_MSG_PROC_AUTH_BOOT - Authenticate Image and Configure Processor
298 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
300 **Purpose**: Provides a means for the host with current control to do the following:
302 - Authenticate and load a binary using the certificate provided information
303 - Use certificate information also to setup critical processor specific
304 flags which is similar to
305 :ref:`Set Processor Configuration <proc-boot-set-processor-configuration>`.
307 **Usage**:
309 +------------------------+--------+
310 | **Message Type** | Normal |
311 +------------------------+--------+
312 | **Secure Queue Only?** | No |
313 +------------------------+--------+
315 **TISCI Message ID**
317 .. sysfwapimacro:: TISCI_MSG_PROC_AUTH_BOOT
319 .. sysfwapistruct:: tisci_msg_proc_auth_boot_req
321 .. attention::
323 * The certificate itself shall contain relevant information about the
324 processor flags and configuration information.
325 * ONLY secure hosts are permitted to invoke this API in addition to
326 being part of the access control list.
327 * See Hosts description for the corresponding SoC to identify which hosts
328 are secure and which are not.
330 .. attention::
332 Please see :doc:`sec_cert_format` for certificate format.
334 .. sysfwapistruct:: tisci_msg_proc_auth_boot_resp
336 .. attention::
337 Reason for failure is NOT provided to prevent security attacks by
338 scan. If permitted, System firmware logs shall provide relevant failure
339 information.
341 .. _proc_boot_get_processor_status:
343 TISCI_MSG_PROC_GET_STATUS - Get Processor Status
344 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
346 **Purpose**: Provides a means for hosts in the permitted list to get the status
347 of a physical processor. This is required for the hosts to sequence events in
348 the correct order
350 **Usage**:
352 +------------------------+--------+
353 | **Message Type** | Normal |
354 +------------------------+--------+
355 | **Secure Queue Only?** | No |
356 +------------------------+--------+
358 **TISCI Message ID**
360 .. sysfwapimacro:: TISCI_MSG_PROC_GET_STATUS
362 .. sysfwapistruct:: tisci_msg_proc_get_status_req
364 .. sysfwapistruct:: tisci_msg_proc_get_status_resp
366 .. attention::
367 Reason for failure is NOT provided to prevent security attacks by
368 scan. If permitted, System firmware logs shall provide relevant failure
369 information.
371 .. _proc_boot_wait_processor_status:
373 TISCI_MSG_PROC_WAIT_STATUS - Wait for Processor Status
374 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
376 **Purpose**: Provides a means for hosts in the permitted list to wait for the
377 status of a physical processor.
379 .. warning::
381 This API that has impact on firmware performance and is typically
382 only required for the hosts to sequence events in the correct order
383 when executing from the processor itself. In short, avoid if possible.
385 The worst case delay could be upto:
386 (register operations and code overheads) +
387 num_wait_iterations(255) * delay_per_iteration_us(255) +
388 delay_before_iteration_loop_start_us (255) =
389 65.280 milli seconds + (register operations and code overheads)
391 **Usage**:
393 +------------------------+--------+
394 | **Message Type** | Normal |
395 +------------------------+--------+
396 | **Secure Queue Only?** | No |
397 +------------------------+--------+
399 **TISCI Message ID**
401 .. sysfwapimacro:: TISCI_MSG_PROC_WAIT_STATUS
403 .. sysfwapistruct:: tisci_msg_proc_status_wait_req
405 .. sysfwapistruct:: tisci_msg_proc_status_wait_resp
407 .. warning::
409 At least one of status_flags_1_set_all_wait, status_flags_1_set_any_wait,
410 status_flags_1_clr_all_wait or status_flags_1_clr_any_wait must be
411 requested.
413 Flags and sequences desired are very specific to processor and SoC involved. Please
414 refer to appropriate documentation for accurate sequencing and status information.
416 .. note::
418 A trivial example for a hypothetical processor status wait could have the parameters as follows:
420 .. code-block:: bash
422 # No optional bits to be set
423 status_flags_1_set_all_wait = 0
425 # Either WFI OR WFE to be set as 1
426 status_flags_1_set_any_wait = WFI | WFE
428 # CLK_STOP must be to be cleared
429 status_flags_1_clr_all_wait = CLK_STOP
431 # No optional status bits to be cleared
432 status_flags_1_clr_any_wait = 0
434 # Check status every ~2 us
435 delay_per_iteration_us = 2
437 # Do not wait to start checks
438 delay_before_iteration_loop_start_us = 0
440 # Check for 10 times before timing out
441 num_wait_iterations = 10
443 # Must match at least for 2 consecutive iterations
444 num_match_iterations = 2
446 .. attention::
447 Reason for failure is NOT provided to prevent security attacks by
448 scan. If permitted, System firmware logs shall provide relevant failure
449 information.
451 .. _proc_boot_flags:
453 Generic Processor Flags
454 -----------------------
456 - config_flags_1 Field Reserved for Generic usage
458 +--------------------+------------+--------------------------------------------------------------------------------------+
459 | Flag Name | Bit Offset | Description |
460 +====================+============+======================================================================================+
461 | GEN_IGN_BOOTVECTOR | 28 | Valid only for :ref:`config_flags_1_clear <proc-boot-set-processor-configuration>` |
462 | | | Flag indicating that SYSFW should not use the bootvector_lo and bootvector_hi fields |
463 | | | in the tisci_msg_proc_set_config_req structure. |
464 +--------------------+------------+--------------------------------------------------------------------------------------+
466 Processor Specific Flags
467 ------------------------
469 This section lists the flags that are specific to each processor types. These
470 flags apply to the :ref:`processor control APIs <proc-boot-processor-control-apis>`.
472 .. note::
474 The |sysfw| does not modify the silicon defaults unless the specific message
475 to update the processor config/control flags is received.
478 ARMV8
479 ^^^^^
481 - config_flags_1 Fields
483 +-------------+------------+-----------------------------------------------+
484 | Flag Name | Bit Offset | Description |
485 +=============+============+===============================================+
486 | DBG_EN | 0 | invasive Debug |
487 +-------------+------------+-----------------------------------------------+
488 | DBG_NIDEN | 1 | Non-invasive Debug |
489 +-------------+------------+-----------------------------------------------+
490 | DBG_SPIDEN | 2 | Secure invasive Debug |
491 +-------------+------------+-----------------------------------------------+
492 | DBG_SPNIDEN | 3 | Secure Non-invasive Debug |
493 +-------------+------------+-----------------------------------------------+
494 | ARCH32 | 8 | 32bit mode (if disabled, implies 64 bit mode) |
495 +-------------+------------+-----------------------------------------------+
497 - control_flags_1 Fields:
499 +------------+------------+---------------------------------------------------------------------+
500 | Flag Name | Bit Offset | Description |
501 +============+============+=====================================================================+
502 | ACINACTM | 0 | Snoop coherency interface state |
503 +------------+------------+---------------------------------------------------------------------+
504 | AINACTS | 1 | ACP interface state |
505 +------------+------------+---------------------------------------------------------------------+
506 | L2FLUSHREQ | 8 | SoC level L2 Flush Request - See L2FLUSH_DONE status for completion |
507 +------------+------------+---------------------------------------------------------------------+
509 .. note::
510 Please refer to SoC Technical Reference Manual and
511 `ARM Technical Reference <http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0500e/CACJFAJC.html>`_
512 for information on sequencing required for startup and shutdown of CPUs in a cluster.
513 Applying these flags to any CPU in a cluster affects the corresponding cluster.
515 - status_flags_1 Fields
517 +--------------+------------+------------------------------------------------+
518 | Flag Name | Bit Offset | Description |
519 +==============+============+================================================+
520 | WFE | 0 | Set if the core is in WFE state |
521 +--------------+------------+------------------------------------------------+
522 | WFI | 1 | Set if the core is in WFI state |
523 +--------------+------------+------------------------------------------------+
524 | L2FLUSH_DONE | 4 | Set if the cluster's L2 flush done is complete |
525 +--------------+------------+------------------------------------------------+
526 | STANDBYWFIL2 | 5 | Set if the cluster's L2 WFI is achieved |
527 +--------------+------------+------------------------------------------------+
529 ARM R5
530 ^^^^^^
532 - config_flags_1 Fields
534 +-------------+------------+-------------------------------------------------------------------------------------------------------------+
535 | Flag Name | Bit Offset | Description |
536 +=============+============+=============================================================================================================+
537 | DBG_EN | 0 | invasive Debug |
538 +-------------+------------+-------------------------------------------------------------------------------------------------------------+
539 | DBG_NIDEN | 1 | Non-invasive Debug |
540 +-------------+------------+-------------------------------------------------------------------------------------------------------------+
541 | LOCKSTEP | 8 | On Write - Enable Lockstep (if permitted) - (1: Lockstep enabled, 0 - Lockstep disabled). |
542 | | | On Read - Core Status - (1: Core in lockstep mode, 0 - Core in split mode) |
543 +-------------+------------+-------------------------------------------------------------------------------------------------------------+
544 | TE_INIT | 9 | Exception handling state at reset (0 - ARM, 1 - Thumb) |
545 +-------------+------------+-------------------------------------------------------------------------------------------------------------+
546 | NMFI_EN | 10 | Enable Core Non-Maskable Fast Interrupts |
547 +-------------+------------+-------------------------------------------------------------------------------------------------------------+
548 | TCM_RSTBASE | 11 | Core A/BTCM Reset Base address Indicator (0 - BTCM located at address 0x0, 1 - ATCM located at address 0x0) |
549 +-------------+------------+-------------------------------------------------------------------------------------------------------------+
550 | BTCM_EN | 12 | Enable Core BTCM RAM at reset |
551 +-------------+------------+-------------------------------------------------------------------------------------------------------------+
552 | ATCM_EN | 13 | Enable Core ATCM RAM at reset |
553 +-------------+------------+-------------------------------------------------------------------------------------------------------------+
555 - control_flags_1 Fields
557 +-----------+------------+-------------+
558 | Flag Name | Bit Offset | Description |
559 +===========+============+=============+
560 | CORE_HALT | 0 | Halt Core |
561 +-----------+------------+-------------+
563 - status_flags_1 Fields
565 +--------------------+------------+------------------------------------------------------+
566 | Flag Name | Bit Offset | Description |
567 +====================+============+======================================================+
568 | WFE | 0 | Set if the core is in WFE state |
569 +--------------------+------------+------------------------------------------------------+
570 | WFI | 1 | Set if the core is in WFI state |
571 +--------------------+------------+------------------------------------------------------+
572 | CLK_GATED | 2 | Core Clock Stopped due to WFI or WFE state |
573 +--------------------+------------+------------------------------------------------------+
574 | LOCKSTEP_PERMITTED | 8 | Is Lockstep configuration permitted - 1: yes, 0 - no |
575 +--------------------+------------+------------------------------------------------------+
577 C7x DSP
578 ^^^^^^^
580 - config_flags_1 Fields
582 +----------------------------+------------+-----------------------------------------------------------------------+
583 | Flag Name | Bit Offset | Description |
584 +============================+============+=======================================================================+
585 | L2_PIPELINE_LATENCY_VALUE | 0-3 | Set C7x Corepac L2 Pipeline latency. valid values: 1 to 5 |
586 +----------------------------+------------+-----------------------------------------------------------------------+
587 | L2_ACCESS_LATENCY_VALUE | 4-7 | Set C7x Corepac L2 Access latency. valid values: 2 to 5 |
588 +----------------------------+------------+-----------------------------------------------------------------------+
590 - control_flags_1 Fields
592 **Not supported.**
594 - status_flags_1 Fields
596 **Not supported.**
598 C6x DSP
599 ^^^^^^^
601 - config_flags_1 Fields
603 +-------------------------------+------------+--------------------------------------------------------------------+
604 | Flag Name | Bit Offset | Description |
605 +===============================+============+====================================================================+
606 | SSCLK_MODE_DIV_CLK_MODE_VALUE | 0-2 | Controls the C66 clock rate for cluster logic and bus interfaces. |
607 | | | (See warning note below) |
608 | | | 0x1 - Div2 clock mode. |
609 | | | 0x2 - Div3 clock mode. |
610 | | | 0x3 - Div4 clock mode. |
611 +-------------------------------+------------+--------------------------------------------------------------------+
613 .. warning::
615 NOTE: Values of SSCLK_MODE_DIV_CLK_MODE_VALUE are TRM value + 1 for
616 avoiding '0' as a valid value which cannot be distinguished from values
617 we are not attempting to set
619 - control_flags_1 Fields
621 **Not supported.**
623 - status_flags_1 Fields
625 **Not supported.**
627 ARM M4F
628 ^^^^^^^
630 .. warning::
632 NOTE: M4F always starts from 0x0 from internal TCM RAM. There is no
633 specific bootvector configuration possible. We need to request the
634 device with reset enabled and load the TCM RAM prior to releasing
635 the reset to allow the processor to execute.
637 - config_flags_1 Fields
639 +-------------+------------+-------------------------------------------------------------------------------------------------------------+
640 | Flag Name | Bit Offset | Description |
641 +=============+============+=============================================================================================================+
642 | DBG_EN | 0 | invasive Debug |
643 +-------------+------------+-------------------------------------------------------------------------------------------------------------+
644 | DBG_NIDEN | 1 | Non-invasive Debug |
645 +-------------+------------+-------------------------------------------------------------------------------------------------------------+
647 - control_flags_1 Fields
649 **Not supported.**
651 - status_flags_1 Fields
653 +--------------------+------------+------------------------------------------------------+
654 | Flag Name | Bit Offset | Description |
655 +====================+============+======================================================+
656 | WFI | 1 | Set if the core is in WFI state |
657 +--------------------+------------+------------------------------------------------------+