diff options
Diffstat (limited to 'docs/firmware-design.md')
| -rw-r--r-- | docs/firmware-design.md | 35 |
1 files changed, 7 insertions, 28 deletions
diff --git a/docs/firmware-design.md b/docs/firmware-design.md index c5a8cba3..68e3f3ad 100644 --- a/docs/firmware-design.md +++ b/docs/firmware-design.md @@ -959,7 +959,7 @@ The sample crash output is shown below. --------------------------------- Trusted Firmware implements a framework that allows CPU and platform ports to -perform actions immediately after a CPU is released from reset in both the cold +perform actions very early after a CPU is released from reset in both the cold and warm boot paths. This is done by calling the `reset_handler()` function in both the BL1 and BL3-1 images. It in turn calls the platform and CPU specific reset handling functions. @@ -968,33 +968,12 @@ Details for implementing a CPU specific reset handler can be found in Section 8. Details for implementing a platform specific reset handler can be found in the [Porting Guide](see the `plat_reset_handler()` function). -When adding functionality to a reset handler, the following points should be -kept in mind. - -1. The first reset handler in the system exists either in a ROM image - (e.g. BL1), or BL3-1 if `RESET_TO_BL31` is true. This may be detected at - compile time using the constant `FIRST_RESET_HANDLER_CALL`. - -2. When considering ROM images, it's important to consider non TF-based ROMs - and ROMs based on previous versions of the TF code. - -3. If the functionality should be applied to a ROM and there is no possibility - of a ROM being used that does not apply the functionality (or equivalent), - then the functionality should be applied within a `#if - FIRST_RESET_HANDLER_CALL` block. - -4. If the functionality should execute in BL3-1 in order to override or - supplement a ROM version of the functionality, then the functionality - should be applied in the `#else` part of a `#if FIRST_RESET_HANDLER_CALL` - block. - -5. If the functionality should be applied to a ROM but there is a possibility - of ROMs being used that do not apply the functionality, then the - functionality should be applied outside of a `FIRST_RESET_HANDLER_CALL` - block, so that BL3-1 has an opportunity to apply the functionality instead. - In this case, additional code may be needed to cope with different ROMs - that do or do not apply the functionality. - +When adding functionality to a reset handler, keep in mind that if a different +reset handling behavior is required between the first and the subsequent +invocations of the reset handling code, this should be detected at runtime. +In other words, the reset handler should be able to detect whether an action has +already been performed and act as appropriate. Possible courses of actions are, +e.g. skip the action the second time, or undo/redo it. 8. CPU specific operations framework ----------------------------- |