Heiko,
> On 19 Sep 2017, at 12:16, Dr. Philipp Tomsich
> <philipp.toms...@theobroma-systems.com> wrote:
>
>>
>> On 19 Sep 2017, at 11:12, Heiko Stübner <he...@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....@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.
Regards,
Philipp.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
