From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko =?ISO-8859-1?Q?St=FCbner?= Date: Thu, 21 Sep 2017 12:44:49 +0200 Subject: [U-Boot] [PATCH v3 0/6] rockchip: back-to-bootrom: replace assembly-implementation with C-code In-Reply-To: <3CDC3C31-933B-4D38-ADE7-F9F9C354505F@theobroma-systems.com> References: <1505981969-49480-1-git-send-email-philipp.tomsich@theobroma-systems.com> <1575654.3LH0U9PvCD@phil> <3CDC3C31-933B-4D38-ADE7-F9F9C354505F@theobroma-systems.com> Message-ID: <1515454.iN24rLG9oW@diego> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de Am Donnerstag, 21. September 2017, 12:25:17 CEST schrieb Dr. Philipp Tomsich: > > On 21 Sep 2017, at 11:44, Heiko Stuebner 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