> On 19 Sep 2017, at 11:12, Heiko Stübner <[email protected]> wrote: > > Am Dienstag, 19. September 2017, 11:10:29 CEST schrieb Dr. Philipp Tomsich: >> Andy, >> >>> On 19 Sep 2017, at 09:19, Andy Yan <[email protected]> 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. _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
