You copied the Doc URL to your clipboard.

Reset hold registers, RST_HOLD0 and RST_HOLD1

The reset hold registers enable a processor to place any core or cluster into a reset state.

The reset is scheduled for when the core to be reset enters the STANDBYWFI state, and remains in reset until another core brings it out of reset.

The following reset hold registers exist:

RST_HOLD0 Toggles resets for the Cortex®‑A15 cluster.
RST_HOLD1 Toggles resets for the Cortex‑A7 cluster.

The following table shows the bits in the RST_HOLDx registers that force a particular reset.

For all supported resets, the reset is held for as long as the corresponding bit in the RST_HOLDx register is HIGH.

Table 3-28 RST_HOLDx register bit assignments

Bits Name Type Description
[8] CLUSTER_RESET RW Write 1 to this bit to reset the entire cluster. The reset is scheduled to occur when every core in the cluster has entered the STANDBYWFI state. The cluster is then held in reset until 0 is written to the field. A cluster reset places each core into a power-on reset and resets the interrupt controller and L2 logic.
[7:4] CPU_PORESET RW Write 1 to bit n to assert a core power-on reset for core n. The reset is scheduled to occur when core n enters the STANDBYWFI state. The reset line is then held indefinitely until 0 is written to the field. A core power-on reset resets the core logic, NEON™/VFP and debug logic.
[3:0] CPU_RESET RW Write 1 to bit n to assert a core reset for core n. The reset is scheduled to occur when core n enters the STANDBYWFI state. The reset line is then held indefinitely until 0 is written to the field. A core reset resets the core logic and NEON/VFP.

Power-on behavior

At power-on, the CLUSTER_RESET fields of the RST_HOLDx registers take their values from the CFG_ACTIVECLUSTER static configuration input.

This means that you can choose the cluster, or clusters, that are active at power-on without re-generating the system. 3.22 Reset architecture describes the CFG_ACTIVECLUSTER static configuration input.

Writing to RST_HOLDx

Writes to RST_HOLDx might not result in the reset being asserted or de-asserted immediately.

Certain conditions must be met before the requested action can be performed, and the reset controller completes the action as soon as possible. The following figure shows the simplest sequence of events when a bit of RST_HOLDx is written from 0 to 1.

Figure 3-1 RST_HOLDx sequence

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


In the figure above, the following actions occur:

  1. Bit n of RST_HOLDx is written to request the assertion of the reset. The reset controller waits for the STANDBYWFI signal from core n to go HIGH.
  2. STANDBYWFI from core n goes HIGH. The reset controller can now assert the reset.
  3. The reset is held for as long as RST_HOLDx[n] is HIGH.
  4. When RST_HOLDx[n] is de-asserted, the reset is released.
  5. Core n is out of reset.

The figure above shows the simple case where the requested reset does not depend on other resets.

Note:

  • A cluster reset is not asserted until STANDBYWFI has been asserted for every core in the cluster.
  • Writing a bit of RST_HOLDx from 1 to 0 only releases the reset when all higher-level resets have been released. For example, higher-level resets always have priority over lower-level resets.
  • Writing a bit of RST_HOLDx from 0 to 1 implicitly resets lower-level resets. For example, writing 1 to only PORESET for core 1 resets both PORESET and CPURESET for core 1.

It is possible to withdraw a requested reset before it has been asserted if the bit of RST_HOLDx is written from 1 to 0 during the 'wait for STANDBYWFI' window. This is the time between points 1 and 2 in the figure above. If the RST_HOLDx request is cleared during this window, then the reset is not asserted, provided that there are no higher-level resets that take priority. When a reset has been asserted, the reset controller ensures that the reset is applied for a minimum of 16 clock cycles.

If the RST_HOLDx request is cleared when the reset has been asserted for fewer than 16 clock cycles, that is, the number of clock cycles between points 3 and 4 in the figure above, is fewer than 16, then the reset is released only when 16 clock cycles have passed.

During this time, writing 1 back to RST_HOLDx cancels the de-assertion of the reset.

Writing 1 to a bit of RST_HOLDx that is already 1, or that is reset implicitly because of a higher-level reset, has no effect on the active resets.

Writing 0 to a bit of RST_HOLDx that is already 0 has no effect.

Reading from RST_HOLDx

Reading the RST_HOLDx register returns the value that was last written to the register.

To determine the resets that are currently active, see 3.21.3 Reset Status Registers, RST_STAT0 and RST_STAT1.

Software sequence to assert reset using RST_HOLDx

For core A to reset Core B, software must perform the following actions:

Note:

Core A and core B can be the same core.
  1. Core A writes to the appropriate RST_HOLDx register to request the reset of core B or its cluster.
  2. Core B programs the GIC of its cluster to prevent IRQs and FIQs being asserted to Core B.
  3. Core B executes a WFI. After Core B executes WFI, its STANDBYWFI output goes HIGH. At this point, the reset controller asserts reset until the register that caused it is cleared, and always for a minimum of 16 clock cycles.

Implicit resets based on requested reset levels

Requesting a cluster reset implies that all core in the cluster are to have PORESETn applied.

Applying PORESETn to a core implies that the core reset is applied. See 3.22 Reset architecture. Writing 1 to a field of RST_HOLDx therefore implicitly forms a reset-assertion request for lower-level fields, as the following table shows. In the table, the symbols w, x, y, and z each represent a logic 1 or 0. A dash represents a don't care value, and a pipe, |, represents a logical OR function. The table also references the RST_STATx registers, that discover the current set of applied resets. See 3.21.3 Reset Status Registers, RST_STAT0 and RST_STAT1.

Table 3-29 Effect of RST_HOLDx write values

Value written to RST_HOLDx Value read from RST_STATx when serviced Description
[8] [7:4] [3:0] [8] [7:4] [3:0] -
0 0000 0000 0 0000 0000 All resets are de-asserted.
0 0000 wxyz 0 0000 wxyz Core resets are asserted for the requested cores, and all other reset lines are de-asserted.
0 wxyz abcd 0 wxyz abcd | wxyz Power-on resets for the requested cores are asserted, together with core reset for the same cores, regardless of the value written in bits [3:0]. Core resets for other explicitly-requested cores are also asserted. All other resets are de-asserted.
1 ---- ---- 1 1111 1111 A cluster reset is asserted, and this means that the core reset and PORESET lines are also asserted.
Was this page helpful? Yes No