[U-Boot] rockchip: add support for backing to bootrom download mode

[Andy Yan]

Hi Philipp:


On 2017年09月13日 16:50, Dr. Philipp Tomsich wrote:
>> On 13 Sep 2017, at 10:36, Andy Yan <andy.yan at rock-chips.com> 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?
>
>
>
>