diff options
| author | Andreas Dannenberg <dannenberg@ti.com> | 2019-08-08 12:54:49 -0500 |
|---|---|---|
| committer | Tom Rini <trini@konsulko.com> | 2019-08-20 12:20:32 -0400 |
| commit | 1425465accfb96b74df400131aeb55665e9d98d2 (patch) | |
| tree | c358d6c4ffd9285a65d1c3ff0480f1213f42e643 | |
| parent | a2ca54ff52146f2bbf52d87bf4e121e8e15e9e07 (diff) | |
README: Clarify use of BSS during SPL board_init_f()
The earlier commit....
commit a5a5d997b41a ("spl: Allow performing BSS init early before board_init_f()")
...introduced the ability to use BSS from SPL's board_init_f() as it may
be required in certain exceptional use cases so go ahead and update the
README to reflect this change. Note that as highlighted with the changes
the use of the associated CONFIG option is generally not recommended.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
| -rw-r--r-- | README | 7 |
1 files changed, 7 insertions, 0 deletions
@@ -267,6 +267,13 @@ board_init_f(): - preloader_console_init() can be called here in extremis - should set up SDRAM, and anything needed to make the UART work - these is no need to clear BSS, it will be done by crt0.S + - for specific scenarios on certain architectures an early BSS *can* + be made available (via CONFIG_SPL_EARLY_BSS by moving the clearing + of BSS prior to entering board_init_f()) but doing so is discouraged. + Instead it is strongly recommended to architect any code changes + or additions such to not depend on the availability of BSS during + board_init_f() as indicated in other sections of this README to + maintain compatibility and consistency across the entire code base. - must return normally from this function (don't call board_init_r() directly) |