diff options
author | Simon Glass <sjg@chromium.org> | 2018-09-02 17:02:24 -0600 |
---|---|---|
committer | Bin Meng <bmeng.cn@gmail.com> | 2018-10-22 17:51:45 +0800 |
commit | 97d20f69f53e7586394e48805f25f23d9a3ebaa8 (patch) | |
tree | dfd6112154979d0c3c5ba97b7446fa48d1528f63 /drivers/rtc/ds174x.c | |
parent | 27fb0cf1f0dd061f5a902928417656488db6301f (diff) |
Enable CONFIG_TIMER_EARLY with bootstage
In initr_bootstage() we call bootstage_mark_name() which ends up calling
timer_get_us(). This call happens before initr_dm(), which inits driver
model.
On x86 we set gd->timer to NULL in the transition from board_init_f()
to board_init_r(). See board_init_f_r() for this assignment. So U-Boot
knows there is no timer available in the period immediately after
relocation.
On x86 the timer_get_us() call is implemented as calls to get_ticks() and
get_tbclk(). Both of these call dm_timer_init() to set up the timer, if
gd->timer is NULL and the early timer is not available.
However dm_timer_init() cannot succeed before initr_dm() is called.
So it seems that on x86 if we want to use CONFIG_BOOTSTAGE we must enable
CONFIG_TIMER_EARLY. Update the Kconfig to handle this.
Note: On most architectures we can rely on the pre-relocation memory still
being available, so that gd->timer pointers to a valid timer device and
everything works correctly. Admittedly this is not strictly correct since
the timer device is set up by pre-relocation U-Boot, but normally this is
fine. On x86 the 'CAR' (cache-as-RAM) memory used by pre-relocation U-Boot
disappears in board_init_f_r() and any attempt to access it will hang.
This is the reason why we must mark the timer as invalid when we get to
board_init_f_r().
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Diffstat (limited to 'drivers/rtc/ds174x.c')
0 files changed, 0 insertions, 0 deletions