[U-Boot] [PATCH v3 0/6] rockchip: back-to-bootrom: replace assembly-implementation with C-code

[Andy Yan]

Hi Philipp, Heiko:


I finally got the upstream u-boot run on a rk3188 board which can be 
attached by DS5 debugger,

if you have some registers info want to check, please let me know.


On 2017年09月21日 18:44, Heiko Stübner wrote:
> Am Donnerstag, 21. September 2017, 12:25:17 CEST schrieb Dr. Philipp Tomsich:
>>> On 21 Sep 2017, at 11:44, Heiko Stuebner <heiko at sntech.de> wrote:
>>>
>>> Am Donnerstag, 21. September 2017, 11:09:49 CEST schrieb Heiko Stuebner:
>>>> Am Donnerstag, 21. September 2017, 10:19:23 CEST schrieb Philipp Tomsich:
>>>>> Recent discussions confirmed (what the code always assumed): the
>>>>> Rockchip BROM always enters U-Boot with the stack-pointer valid
>>>>> (i.e. the U-Boot startup code is running off the BROM stack).
>>>>>
>>>>> We can thus replace the back-to-bootrom code (i.e. both the
>>>>> save_boot_params and back_to_bootrom implementations) using C-code
>>>>> based on setjmp/longjmp.  The new implementation is already structured
>>>>> to allow an easy drop-in of Andy's changes to enter download-mode when
>>>>> returning to the BROM.
>>>>>
>>>>> This turned out to require a some tweaking to system.h (making sure
>>>>> that the prototype for save_boot_params_ret is visible for A64)and
>>>>> start.S (so binutils knows that this is a possible function entry and
>>>>> it can correctly insert A32-to-Thumb transitions) and taking the axe
>>>>> to setjmp.h (which created quite a few issues with it not expecting
>>>>> A32/T32/Thumb call-sites and some fragility from GCC being smart about
>>>>> the clobber-list of the inline assembly... which led to r9 not being
>>>>> saved or restored).
>>>> This is missing information on dependant series. Using the
>>>> u-boot-rockchip
>>>> repository which is at
>>>> 782088de7be7 ("rockchip: imply ADC and SARADC_ROCKCHIP on supported
>>>> SoCs")
>>>>
>>>> patches 1-3 apply, but patch 4 fails to apply as I seem to be missing
>>>> some
>>>> dependencies.
>>>>
>>>> And the u-boot mailinglist seems to be configured very strangely, as it
>>>> seems to rip apart patch-series only sending me some parts.
>>>>
>>>> So far I can at least say, that the u-boot-rockchip repo at the above
>>>> commit still boots. Could you please point me to mbox versions
>>>> of needed base patches?
>>> Also, with patches 1-3 and 5 applied the radxarock board fails to start.
>>> I see the SPL banner and a "Returning to boot ROM..." and then nothing.
>>>
>>> I do belive it may have something to do with the TPL's + SPL's stack both
>>> being at the end of SRAM? Having the SPL go back to TPL and then
>>> back to bootrom was my original intention as well, but didn't work at
>>> the time.
>> I didn’t expect the stacks to overlap… so returning from SPL to TPL can’t
>> work.  However, the jump_to_spl() is at least partially to blame (we already
>> have a working C-runtime and there’s no point in reentering through the
>> reset entry-point).
>>
>> I need to ponder this a bit, but my gut feeling is that the TPL->SPL
>> transition can be done in a less intrusive way and may allow us to retain
>> the TPL stack.
> Alternatively, if you can think of an easier solution we could do away with
> the TPL in its current form. When I did the rk3188 support, this looked like
> the least-messy way to me, but it really only does the one jump back
> to the bootrom - so I'm not sure if there isn't simply an easier solution.
>
> And for example the (still wip?) rk3066 series did use spl+tpl in a different
> way due to bootrom-nand-limitations. rk3066 and rk3188 are quite similar
> with the rk3066 simply not having the sd-boot capability, so if we want to
> have nand-boot on rk3188 as well in the future, this may need a different
> rework again.
>
>
> Heiko
>
>
>