On 2019/9/18 下午1:25, Jagan Teki wrote:
On Wed, Sep 18, 2019 at 10:36 AM Kever Yang <kever.y...@rock-chips.com> wrote:
On 2019/9/17 下午2:10, Jagan Teki wrote:
SPL sets up SDRAM while in its board_init_f()
function, it is possible for the stack to move
there before board_init_r() is reached.
So it is required to reserve the stack for SDRAM,
with a proper location and size otherwise any
operations during SPL handoff would leads to failure.
On, this particular context tinker-rk3288 SPL is
failing to launch U-Boot proper on SDRAM due to
lack of stack.
If no SPL_STACK_R, it should still use CONFIG_SPL_STACK when system
init, right?
SPL_STACK vs SPL_STTACK_R would be different in their usage former is
used to setup the stack during early while calling board_init_f but
the later used to setup the stack (with DRAM base) while calling
board_init_r. if CONFIG_SPL_STACK_R is defined, then at this point the
stack and global_data are relocated to below CONFIG_SPL_STACK_R_ADDR.
CONFIG_SPL_STACK_R_ADDR - 0x80000 (this would be as part of sdram map)
CONFIG_SPL_STACK - 0xff718000 (this address where SDRAM not been used)
Since the issue, is due to launch U-Boot proper from mmc, the stack
that SPL during that time was not set it up.
I think the root cause is: the master of emmc controller can no access
SRAM, and the emmc init
driver needs to use memory based on CONFIG_SPL_STACK, if this is in
SRAM, then the emmc driver
will init fail, and 'fifo-mode' can work around this issue. So the
CONFIG_SPL_STACK_R is needed
for emmc/sd controller driver.
Thanks,
- Kever
It sounds like this should not cause failure if there no one touch the
CONFIG_SPL_STACK area.
I remember while implementing TPL, on vyasa I do take care of this
STACK_R, so same been reused it for tinker.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
