HRESET_B and RESET_REQ_B expectations in error conditions

[scottgerhold]

When the T2080 is configured to read the RCW from SPI and there are errors determined in the SPI (bad address, bad CRC etc.) what are the expected states for these signals.

For example if the RCW itself is corrupted (some possible errors (not a complete list): a) corrupt preamble, b) illegal address, c) CRC error). Will the HRESET_B signal stay low when RESET_REQ_B is asserted low? Or will HRESET_B transition high. In the Ref Manual, it states in step 12 of section 4.6.1 that it waits for the PBL RCW to be completed (loading of all 512 bits). If the PBL reports an error during its process of loading the RCW data, the device reset sequence is halted indefinitely, waiting for another PORESET_B or hard reset. If HRESET_B isn't deasserted it seems impossible to cause a hard reset (you can assert PORESET_B at this point). It isn't until step 14 that HRESET_B goes high. There is not specific mention that RESET_REQ_B gets asserted, but I am assuming that is part of the error response.

Now what if the RCW passes (with a CRC placed directly after the RCW) but an error occurs in the PBL PBI commands that follow the RCW phase. I am assuming in this case that HRESET_B signal transitioned high after the RCW is loaded, before PBL PBI command loading is complete? So in this case it should definitely be HRESET_B = 1, RESET_REQ_B = 0?

It seems that ASLEEP is also usable to help decode states in this phase. However it appears that ASLEEP will be asserted (high) until both RCW and PBL PBI phases are complete (step 18 - System ready state). Thus it is possible that we could use ASLEEP to help determine when RESET_REQ_B assertions are the result of RCW/PBL or something after that phase. We are looking for ways in which we can signal to a technician that a boot up error is the result of the SPI PROM contents instead of something with the power supplies or boot SW.

What I am looking for is a definitive set of waveforms (or state diagram) that defines when the HRESET_B, RESET_REQ_B and ASLEEP signals would transition as it relates to the RCW/PBL phases.

[scottgerhold]

5.4.1 only says that RESET_REQ_B will be asserted, but does not specify what happens to HRESET_B (does it remain asserted).

5.4.4 only defines what types of errors that could occur, but not what happens with the pins I am asking about. It mentions that the error is sent to the platform is all. We have issues being able to read the error registers because the device is held in reset. That is part of the reason we are trying to chase down being able to detect this case to keep from asserting reset and holding it there.

5.4.5 again defines the types of errors but provides no guidance on the states of the discretes. 

Table 5-5 defines the types of errors we'd expect to see. The reality is that only 0x70-0x7A are applicable to our situation with a SPI attached PROM (not eSDHC or I2C). But that is only useful if we can gain control of the processor with an emulator to get that information out. Our current designs tend to hold the processor in reset in this event (we try 16 times to boot). That kind of tells me that in some cases anyway that the HRESET_B must be going high.

My concern is that if HRESET_B remains asserted that there is no way to gain control with an emulator to even read the error registers. Whether the error occurs in the RCW phase or the following PBI commands phase doesn't really matter, unless the discretes react differently between them. Then we'd need to understand both to detect them and react the same way to either. Since RESET_REQ_B can be asserted much later in the "life" of the power cycle we can't just say that whenever RESET_REQ_B is asserted it is because of power up issue with the PROM. So if we can combine that with the state of ASLEEP it would be good. So again I'd like to know if ASLEEP will be asserted through this entire phase until after the PBL completes all action and SW starts executing code on Core 0.

[ufedor]

PORESET_B/HRESET_B/RESET_REQ_B/ASLEEP behaviour:

   - PORESET_B: This is an input signal driven by the board.

                             It requires minimum 1ms of assertion time

   - HRESET_B

     Once PORESET_B is asserted and negated, HRESET_B will continue to be asserted during RCW

     phase. If RCW is successful, HRESET_B will be negated and proceed to PBI phase.

   - RESET_REQ_B

     If anything is wrong during RCW or PBI phase, RESET_REQ_B will be asserted.

     For the production board, RESET_REQ_B assertion typically leads to PORESET_B or HRESET_B

     Note: In order to help debug, assertion of RESET_REQ_B should not produce PORESET_B/HRESET_B

   - ASLEEP

     ASLEEP is asserted throughout the power up sequence.  Once the reset state machine reaches

     SYSTEM_READY state, ASLEEP will be negated.

It is possible to try pre-built SPI U-Boot binary image provided in the QorIQ Linux SDK v2.0 PPC64E6500 IMAGE ISO:

https://freescaleesd.flexnetoperations.com/337170/477/10318477/QorIQ%20Linux%20SDK%20v2.0%20PPC64E65... 

[ufedor]

Please refer to the QorIQ T2080 Reference Manual,

5.4.1 Device configuration using reset configuration word (RCW)

5.4.4 RCW loading by PBL

5.4.5 Pre-boot initialization command loading by PBL