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

[Heiko Stübner]

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