From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Stuebner Date: Thu, 21 Sep 2017 10:51:44 +0200 Subject: [U-Boot] [PATCH v2 0/5] rockchip: back-to-bootrom: replace assembly-implementation with C-code In-Reply-To: <8DE3D47B-2726-4102-827B-B3DEADB680DB@theobroma-systems.com> References: <1505758708-29213-1-git-send-email-philipp.tomsich@theobroma-systems.com> <291C798E-9B85-4258-96DF-CB27F35B684A@theobroma-systems.com> <8DE3D47B-2726-4102-827B-B3DEADB680DB@theobroma-systems.com> Message-ID: <2813171.BXQzRi5DZL@phil> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de Hi Philipp, Am Donnerstag, 21. September 2017, 10:26:19 CEST schrieb Dr. Philipp Tomsich: > > On 19 Sep 2017, at 12:16, Dr. Philipp Tomsich wrote: > > > >> > >> On 19 Sep 2017, at 11:12, Heiko Stübner wrote: > >> > >> Am Dienstag, 19. September 2017, 11:10:29 CEST schrieb Dr. Philipp Tomsich: > >>> Andy, > >>> > >>>> On 19 Sep 2017, at 09:19, Andy Yan wrote: > >>>> > >>>> Hi Philipp: > >>>> > >>>> On 2017年09月19日 10:06, Andy Yan wrote: > >>>>> Hi Philipp: > >>>>> > >>>>> On 2017年09月19日 02:18, Philipp Tomsich wrote: > >>>>>> 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 entails one minor tweak to asm/system.h, which only exported > >>>>>> the save_boot_params_ret prototype for ARMv7, but not for AArch64. > >>>>>> > >>>>>> For v2, we force bootrom.o to alway be emitted as A32 (not T32), so we > >>>>>> can safely call save_boot_params_ret(). > >>>>>> > >>>>> This still have a problem, because the setjmp implementation for > >>>>> ARM32 platform has humb code when CONFIG_SYS_THUMB_BUILD is>> > >>>>> enabled, this is a default setting for most ARMv7 boards. > >>>>> #if CONFIG_IS_ENABLED(SYS_THUMB_BUILD) > >>>>> ".align 2\n" > >>>>> "adr r0, jmp_target\n" > >>>>> "add r0, r0, $1\n" // r0 stored the jump target address and with bit[0] > >>>>> = 1, this will trigger a thumb switch in longjmp with code "bx r0" > >>>>> #endif > >>>>> > >>>>> When I force the setjmp code go arm code path, I can back to bootrom > >>>>> successfully, But I got a data abort exception in later. it seems it > >>>>> happens when bootrom finished the uboot code copy, when jump to sdram, I > >>>>> need a further debug. > >>>> > >>>> I found that r9 also need to be preserved, it seems that it hold the sdram > >>>> base. > >>> Thanks for testing and debugging: this is invaluable support, as I only have > >>> AArch64 boards to test. > >>> > >>> The r9 issue will be easy enough to resolve. > >>> However, it looks like I will need more work on setjmp/longjmp to make this > >>> safe both for T32 and A32. Plus: I need to figure out why this didn’t show > >>> in my disassembly (I don’t remember whether it was a rk3188 or rk3288 board > >>> I looked at). > >>> > >>> Might be tomorrow or Thursday until I can provide an new version. > >> > >> From this conversation, it looks to me that I should wait for that new > >> version for testing on rk3188, as it will likely show the same issues, right? > > > > Yes. > > A new version with a reworked setjmp/longjmp implementation is available at > https://patchwork.ozlabs.org/project/uboot/list/?series=4327 > > This passed testing for Andy (see the Tested-by: credit) on the boards he works > on, but is still pending a test of a RK3188. Testing that v3 is actually the thing I currently doing, after I found the v3 in my inbox :-) . Results shortly in the v3 series. Heiko