> On 21 Sep 2017, at 12:25, Dr. Philipp Tomsich > <[email protected]> wrote: > >> >> On 21 Sep 2017, at 11:44, Heiko Stuebner <[email protected] >> <mailto:[email protected]>> 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.
I had to draw this out on a whiteboard to keep track of what stacks are in use and when they get destroyed (or returned to). Clearly, returning to the TPL and expecting the C-runtime there to be intact will not work. The problem is that when returning to jump_to_spl(), the TPL’s stack will have been overwritten by SPL. I’ll need to look at the disassembly, but it might be sufficient if I chain into the longjmp directly in jump_to_spl()… or I may need to do something disruptive (e.g. switch stacks) in jump_to_spl. Regards, Philipp. _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
