Hi Philipp:
On 2017年09月13日 16:50, Dr. Philipp Tomsich wrote:
On 13 Sep 2017, at 10:36, Andy Yan <[email protected]> wrote:
If you just always save the boot_params and check the download flag later from
C code, then you could have this implemented in C. This will remove the need to
write two separate assembly functions (for AArch64 and AArch32) and generally
be more readable. Please revise.
We can't predict how many settings the TPL/SPL startup code changed now and
future
will affect the bootrom download function, So back to bootrom download mode
before
anything been changed is a simple way.
Ok. I’d still like to have this in C.
The only requirement for this will be having a valid stack-pointer, so we
should be able to do this early (before the various initialisation runs).
I think board_init_f() would be a suitable place.
When I hack this function first time, I indeed wrote a c implemented code
in board_init_f on kylin-rk3036, but the usb failed connect to my PC
when back to bootrom, after a long time checking whit the bootrom code author,
we found the interrupts related configurations are changed.
Then I try to save and restore the VBAR, then the bootrom download function
works. But when I tested this function on rk3288 based board, it failed
again, and I found rk3288 bootrom require a different interrupt configuration
with rk3036 after a long time dig, the interrupts vector base should be
0xffff0000(other arm32 based boards are 0x0000), so the V bit of SCTLR should
be set to 1, but the SPL startup code set it to zero.
Then I have the idea back to bootrom download mode as early as possible
when the download flag is set, Because no matter how many parameters
I saved and restored today, no one can make sure that other parameters will
not changed by start.S in the future(maybe more properties changed about
the interrupt, maybe the change of mmu /caches, ), because we always have the
chance to modify the startup code by the desire of new feature or the need
to workaround something for a new soc, what's more the start.S it's now have
many #if / #else configuration, this still have risk to change the default
configurations
which will be used in bootrom download mode. If we rely on a save and restore
policy, this function may work well today, but may failed some days later just
because
some one changed another configuration in start.S.
When looking at what happens (on armv7) between the save_boot_params
and the call to _main (which in turn just sets up SP and calls into
board_init_f),
there isn’t much happening: it really is only cpu_init_cp15 and cpu_init_crit
that will be of concern.
The bellow codes changes the V bit and VBAR address, that are what
cause problems on rockchip armv7 based boards.
As for armv7, I haven't check what will cause problem.
As bootrom is a very critical environment and very hard to debug, So
I hope to keep it as clean as possible when we jump back to it.
/*
* Setup vector:
* (OMAP4 spl TEXT_BASE is not 32 byte aligned.
* Continue to use ROM code vector only in OMAP4 spl)
*/
#if !(defined(CONFIG_OMAP44XX) && defined(CONFIG_SPL_BUILD))
/* Set V=0 in CP15 SCTLR register - for VBAR to point to vector */
mrc p15, 0, r0, c1, c0, 0 @ Read CP15 SCTLR Register
bic r0, #CR_V @ V = 0
mcr p15, 0, r0, c1, c0, 0 @ Write CP15 SCTLR Register
/* Set vector address in CP15 VBAR register */
ldr r0, =_start
mcr p15, 0, r0, c12, c0, 0 @Set VBAR
#endif
I really wonder whether we could have a sufficient C runtime (i.e. SP valid)
available before those run.
Does your BROM always call us with the SP valid (I know that that’s the case
on the RK3399 and RK3368), so that we could run on the BROM’s stack here?
_______________________________________________
U-Boot mailing list
[email protected]
https://lists.denx.de/listinfo/u-boot
