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

[Heiko Stuebner]

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 <philipp.tomsich at theobroma-systems.com> wrote:
> > 
> >> 
> >> On 19 Sep 2017, at 11:12, Heiko Stübner <heiko at sntech.de> wrote:
> >> 
> >> Am Dienstag, 19. September 2017, 11:10:29 CEST schrieb Dr. Philipp Tomsich:
> >>> Andy,
> >>> 
> >>>> On 19 Sep 2017, at 09:19, Andy Yan <andy.yan at rock-chips.com> 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