> On 21 Sep 2017, at 11:44, Heiko Stuebner <he...@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.
Regards,
Philipp.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
