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

[Dr. Philipp Tomsich]

Andy,

> On 19 Sep 2017, at 11:10, Dr. Philipp Tomsich <philipp.tomsich at theobroma-systems.com> wrote:
> 
> 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).

I had a quick look and things may be quicker to resolve than I thought.
Before I create a new version, I was wondering what the requirements on the BROM end are:
Without changes to setjmp/longjmp, I can currently preserve "r4-r11, lr, sp” (i.e "r1-r3, ip" will be clobbered).
If the BROM need any of these additional registers preserved (i.e. r1,r2,r3,ip): let me know and I will change setjmp/longjmp to be more conservative.