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

Andy Yan
2017-09-20T01:51:51Z

Hi Philipp:

On 2017年09月19日 20:45, Dr. Philipp Tomsich wrote:
> Andy,
>
>> On 19 Sep 2017, at 11:10, Dr. Philipp Tomsich
>> <philipp.tomsich@theobroma-systems.com
>> <mailto:philipp.tomsich@theobroma-systems.com>> wrote:
>>
>> Andy,
>>
>>> On 19 Sep 2017, at 09:19, Andy Yan <andy.yan@rock-chips.com
>>> <mailto:andy.yan@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.
>

The BROM code that call TPL/SPL also write in C like bellow:
fp = (pFunc)(ptr + 4);
ret = (*fp)(); // fp point to TPL/SPL first address
if (ret)
return;
ptr = (uint8*)SDRAM_ADDR;

So the code doesn't touch the register directly, It's the compile stored
SDRAM_ADDR in r9(I saw it on rk3036 platform).